[jira] [Commented] (TS-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
[ https://issues.apache.org/jira/browse/TS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911428#comment-13911428 ] Zhao Yongming commented on TS-2184: --- when Cluster is designed, the origin goal is to have ONLY one single valid content in the cluster, that is a good idea when you have very huge volume contents, and we have continued on this target, make sure even when some of the machines flapping in the cluster , to ensure that at anytime there is only one valid content in the cluster. but consider of the ICP protocol and others, those may have multiple same content in the ICP cluster, and if you make it complex, it may have multi-version content in the cluster at sometime. so, ICP alike protocols is consider as a not so cool(safe) protocol if you need to enforce of the consistency of the contents you provide to the user agents. back to this requirement, we can make the cluster act like ICP, first write to the cluster hashing machine, and the second or later read poll that content from the cluster and write to the local, but it will introduce the consistency problem here, you don't know who have that content local in the cluster when it is updated on the origin side, within the freshness. in most case, all write to the cache haveto broadcast to all the machines in the cluster, to enforce that change. the proxy.config.http.cache.cluster_cache_local enabled is a directive to disable cluster hashing in the cluster mode, our origin target is to use it to put some very hot hostnames(or urls) in the local, to reducing the intro-cluster traffic. proxy.config.http.cache.cluster_cache_local enabled is override-able and we have the same directive in the cache.config too. if it is in active, Cluster may consider as mode=3, the single host mod. so, if we want to achive ICP alike feature in cluster, mostly we should: 1, write the content on the hashing machine, if it is a miss in the cluster 2, read the cluster if it is missing in the local machine 3, write the local if it is a hit in the cluster 4, broadcast the change to all the machines in the cluster, if it is a overwrite(ie, revalidating etc) 5, purge on the hashing machine and broadcast the purge to all the machines in the cluster it will be a very big change in the Cluster and http transaction cc [~zwoop] Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled --- Key: TS-2184 URL: https://issues.apache.org/jira/browse/TS-2184 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Reporter: Scott Harris Assignee: Bin Chen Fix For: 6.0.0 With proxy.config.http.cache.cluster_cache_local enabled I would like cluster nodes to store content locally but try to retrieve content from the cluster first (if not cached locally) and if no cluster nodes have content cached then retrieve from origin. Example - 2 Cluster nodes in Full cluster mode. 1. Node1 and Node2 are both empty. 2. Request to Node1 for http://www.example.com/foo.html;. 3. Query Cluster for object 4. Not cached in cluster so retrieve from orgin, serve to client, object now cached on Node1. 5. Request comes to Node2 for http://www.example.com/foo.html;. 6. Node2 retrieves cached version from Node1, serves to client, stores locally. 7. Subsequent request comes to Node1 or Node2 for http://www.example.com/foo.html;, object is served to client from local cache. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
[ https://issues.apache.org/jira/browse/TS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911434#comment-13911434 ] Zhao Yongming commented on TS-2184: --- for the very HOT content in the cluster, we have another solution that tracking of the hot content(in traffic view) and put them in the cluster_cache_local list to make it dynamic. and this solution will need a workaround of the purging, you need to broadcast all the purging to every machines in the cluster. and pull from the hashing machine in the cluster is not implemented too. we are testing to see how cool it will be. this function is provide by [~happy_fish100] FYI Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled --- Key: TS-2184 URL: https://issues.apache.org/jira/browse/TS-2184 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Reporter: Scott Harris Assignee: Bin Chen Fix For: 6.0.0 With proxy.config.http.cache.cluster_cache_local enabled I would like cluster nodes to store content locally but try to retrieve content from the cluster first (if not cached locally) and if no cluster nodes have content cached then retrieve from origin. Example - 2 Cluster nodes in Full cluster mode. 1. Node1 and Node2 are both empty. 2. Request to Node1 for http://www.example.com/foo.html;. 3. Query Cluster for object 4. Not cached in cluster so retrieve from orgin, serve to client, object now cached on Node1. 5. Request comes to Node2 for http://www.example.com/foo.html;. 6. Node2 retrieves cached version from Node1, serves to client, stores locally. 7. Subsequent request comes to Node1 or Node2 for http://www.example.com/foo.html;, object is served to client from local cache. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
[ https://issues.apache.org/jira/browse/TS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911666#comment-13911666 ] Leif Hedstrom commented on TS-2184: --- That's a long list of things that needs to be added. Maybe we should turn this into an umbrella / meta bug, and break it out into a few, more manageable tasks? For example, all I really need is #2 feature above. I would simply turn on cluster_cache_local globally (for every object), which gives me something similar to HTCP. Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled --- Key: TS-2184 URL: https://issues.apache.org/jira/browse/TS-2184 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Reporter: Scott Harris Assignee: Bin Chen Fix For: 6.0.0 With proxy.config.http.cache.cluster_cache_local enabled I would like cluster nodes to store content locally but try to retrieve content from the cluster first (if not cached locally) and if no cluster nodes have content cached then retrieve from origin. Example - 2 Cluster nodes in Full cluster mode. 1. Node1 and Node2 are both empty. 2. Request to Node1 for http://www.example.com/foo.html;. 3. Query Cluster for object 4. Not cached in cluster so retrieve from orgin, serve to client, object now cached on Node1. 5. Request comes to Node2 for http://www.example.com/foo.html;. 6. Node2 retrieves cached version from Node1, serves to client, stores locally. 7. Subsequent request comes to Node1 or Node2 for http://www.example.com/foo.html;, object is served to client from local cache. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
[ https://issues.apache.org/jira/browse/TS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911667#comment-13911667 ] Leif Hedstrom commented on TS-2184: --- Oh, and thanks for the writeup! Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled --- Key: TS-2184 URL: https://issues.apache.org/jira/browse/TS-2184 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Reporter: Scott Harris Assignee: Bin Chen Fix For: 6.0.0 With proxy.config.http.cache.cluster_cache_local enabled I would like cluster nodes to store content locally but try to retrieve content from the cluster first (if not cached locally) and if no cluster nodes have content cached then retrieve from origin. Example - 2 Cluster nodes in Full cluster mode. 1. Node1 and Node2 are both empty. 2. Request to Node1 for http://www.example.com/foo.html;. 3. Query Cluster for object 4. Not cached in cluster so retrieve from orgin, serve to client, object now cached on Node1. 5. Request comes to Node2 for http://www.example.com/foo.html;. 6. Node2 retrieves cached version from Node1, serves to client, stores locally. 7. Subsequent request comes to Node1 or Node2 for http://www.example.com/foo.html;, object is served to client from local cache. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2169) SSL statistics
[
https://issues.apache.org/jira/browse/TS-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911670#comment-13911670
]
ASF GitHub Bot commented on TS-2169:
GitHub user rwbarber2 opened a pull request:
https://github.com/apache/trafficserver/pull/46
TS-2169 SSL Stats
Switched to pull request due to anticipated need to merge with more recent
version of master in the future (when this gets pulled finally).
In addition to the stats already documented above, this also includes
cipher stats. Here's the excerpt from the traffic_line doc:
proxy.process.ssl.cipher.user_agent.{cipherName}
Total number of ssl client connections that used cipherName. The list of
cipher stats is dynamic and depends upon the installed ciphers for the
system. Some common cipher stats are:
proxy.process.ssl.cipher.user_agent.ECDHE-RSA-RC4-SHA
proxy.process.ssl.cipher.user_agent.ECDHE-RSA-AES128-SHA256
proxy.process.ssl.cipher.user_agent.ECDHE-RSA-AES128-GCM-SHA256
proxy.process.ssl.cipher.user_agent.ECDHE-RSA-AES128-SHA
proxy.process.ssl.cipher.user_agent.RC4-SHA
proxy.process.ssl.cipher.user_agent.RC4-MD5
proxy.process.ssl.cipher.user_agent.AES128-GCM-SHA256
proxy.process.ssl.cipher.user_agent.AES128-SHA
There are two ways to get the list of cipher stats:
1. Run ATS with debug logging and show ssl diags:
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING ssl.*
View output of traffic.out looking for lines like:
(ssl) Registering ssl cipher stat
'proxy.process.ssl.cipher.user_agent.ECDHE-RSA-AES256-GCM-SHA384'
2. Run this script (just asks openssl to tell us):
openssl ciphers | awk '{n=split($0,a,:); for (i = 0; ++i = n;)
print proxy.process.ssl.cipher.user_agent. a[i];}'
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rwbarber2/trafficserver issues/TS-2169
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/trafficserver/pull/46.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #46
commit 4b7b59756970a805126bb0c43ad93247a2764bf1
Author: Ron Barber rbar...@yahoo-inc.com
Date: 2014-02-25T15:36:23Z
TS-2169 SSL Stats
SSL statistics
--
Key: TS-2169
URL: https://issues.apache.org/jira/browse/TS-2169
Project: Traffic Server
Issue Type: Improvement
Components: SSL, Stats
Reporter: David Carlin
Assignee: Bryan Call
Labels: Review
Fix For: 5.1.0
It would be swell if there were some traffic_line SSL statistic variables.
For instance, number of SSL connections and SSL bytes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2169) SSL statistics
[ https://issues.apache.org/jira/browse/TS-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Barber updated TS-2169: --- Attachment: (was: TS-2169.patch) SSL statistics -- Key: TS-2169 URL: https://issues.apache.org/jira/browse/TS-2169 Project: Traffic Server Issue Type: Improvement Components: SSL, Stats Reporter: David Carlin Assignee: Bryan Call Labels: Review Fix For: 5.1.0 It would be swell if there were some traffic_line SSL statistic variables. For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2184) Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled
[ https://issues.apache.org/jira/browse/TS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2184: -- Fix Version/s: (was: 6.0.0) sometime Fetch from cluster with proxy.config.http.cache.cluster_cache_local enabled --- Key: TS-2184 URL: https://issues.apache.org/jira/browse/TS-2184 Project: Traffic Server Issue Type: Improvement Components: Cache, Clustering Reporter: Scott Harris Assignee: Bin Chen Fix For: sometime With proxy.config.http.cache.cluster_cache_local enabled I would like cluster nodes to store content locally but try to retrieve content from the cluster first (if not cached locally) and if no cluster nodes have content cached then retrieve from origin. Example - 2 Cluster nodes in Full cluster mode. 1. Node1 and Node2 are both empty. 2. Request to Node1 for http://www.example.com/foo.html;. 3. Query Cluster for object 4. Not cached in cluster so retrieve from orgin, serve to client, object now cached on Node1. 5. Request comes to Node2 for http://www.example.com/foo.html;. 6. Node2 retrieves cached version from Node1, serves to client, stores locally. 7. Subsequent request comes to Node1 or Node2 for http://www.example.com/foo.html;, object is served to client from local cache. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2563) Set the SSL default verify paths when ssl.client.verify.server=1
[ https://issues.apache.org/jira/browse/TS-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2563: Labels: (was: Review) Set the SSL default verify paths when ssl.client.verify.server=1 Key: TS-2563 URL: https://issues.apache.org/jira/browse/TS-2563 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 5.0.0 Attachments: TS-2563.diff When working at reverse proxy mode with the following remap rule: map https://xxx1.com https://xxx2.com ssl.client.verify.server=1 If xxx2.com is providing trusted certificate and 'ssl.client.CA.cert.filename' is NULL, ats should be able to verify the certificate in terms of the default provided CAs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2563) Set the SSL default verify paths when ssl.client.verify.server=1
[ https://issues.apache.org/jira/browse/TS-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2563: Component/s: SSL Set the SSL default verify paths when ssl.client.verify.server=1 Key: TS-2563 URL: https://issues.apache.org/jira/browse/TS-2563 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 5.0.0 Attachments: TS-2563.diff When working at reverse proxy mode with the following remap rule: map https://xxx1.com https://xxx2.com ssl.client.verify.server=1 If xxx2.com is providing trusted certificate and 'ssl.client.CA.cert.filename' is NULL, ats should be able to verify the certificate in terms of the default provided CAs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2563) Set the SSL default verify paths when ssl.client.verify.server=1
[ https://issues.apache.org/jira/browse/TS-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911730#comment-13911730 ] ASF subversion and git services commented on TS-2563: - Commit a64033ad5d5e80489c89f0d1d478dedc8c9109c2 in trafficserver's branch refs/heads/master from [~sunwei] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a64033a ] TS-2563: always set the SSL default verify paths When working at reverse proxy mode with the following remap rule: map https://xxx1.com https://xxx2.com ssl.client.verify.server=1 If xxx2.com is providing trusted certificate and 'ssl.client.CA.cert.filename' is NULL, ats should be able to verify the certificate in terms of the default provided CAs. Set the SSL default verify paths when ssl.client.verify.server=1 Key: TS-2563 URL: https://issues.apache.org/jira/browse/TS-2563 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: Wei Sun Assignee: James Peach Fix For: 5.0.0 Attachments: TS-2563.diff When working at reverse proxy mode with the following remap rule: map https://xxx1.com https://xxx2.com ssl.client.verify.server=1 If xxx2.com is providing trusted certificate and 'ssl.client.CA.cert.filename' is NULL, ats should be able to verify the certificate in terms of the default provided CAs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-346) ATS does not verify server certificate
[ https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911734#comment-13911734 ] James Peach commented on TS-346: TS-2563 implies that this works. [~sunwei] can you confirm or deny? ATS does not verify server certificate -- Key: TS-346 URL: https://issues.apache.org/jira/browse/TS-346 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: vijaya bhaskar mamidi Priority: Critical Labels: A Fix For: 5.1.0 ATS does not verify the certificates correctly. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2588) Parent proxy to self fails to loop detect
Leif Hedstrom created TS-2588: - Summary: Parent proxy to self fails to loop detect Key: TS-2588 URL: https://issues.apache.org/jira/browse/TS-2588 Project: Traffic Server Issue Type: Improvement Components: Configuration, HTTP Reporter: Leif Hedstrom As a safety measure, I think it'd be a good idea to not proxy to self in a parent proxy setup. If such a loop is detected, it should instead go to origin directly (bypass parent). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2589) Headers delayed until the origin server starts sending content
Jack Bates created TS-2589: -- Summary: Headers delayed until the origin server starts sending content Key: TS-2589 URL: https://issues.apache.org/jira/browse/TS-2589 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates If there is a transform (for example a null transform) then the response headers aren't forwarded until the origin server starts sending content. Normally (without a transform) the headers are forwarded as soon as they are done, whether content is available yet or not. The headers are sent when the transform calls TSVConnWrite() and the transform is called at the end of the headers/start of the content. But it's not called if the available content is empty. A possible fix is to call the transform at the start of the content whether content is available yet or not. This doesn't affect a buffered transform which can still delay and update the headers until it calls TSVConnWrite() -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-346) ATS does not verify server certificate
[
https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911790#comment-13911790
]
Leif Hedstrom commented on TS-346:
--
Hmmm, I tested this again (same setup, enable verify, and provide the CA that
comes with Fedora), I get a different crash now:
{code}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7289d700 (LWP 1762)]
SSL_connect (s=0x0) at ssl_lib.c:945
945 if (s-handshake_func == 0)
Missing separate debuginfos, use: debuginfo-install tcl-8.5.7-6.el6.x86_64
(gdb) bt
#0 SSL_connect (s=0x0) at ssl_lib.c:945
#1 0x006774c8 in SSLNetVConnection::sslClientHandShakeEvent
(this=0x7fffec19e580, err=@0x7289cc5c)
at ../../../../iocore/net/SSLNetVConnection.cc:611
#2 0x00679739 in SSLNetVConnection::sslStartHandShake
(this=0x7fffec19e580, event=value optimized out,
err=@0x7289cc5c) at ../../../../iocore/net/SSLNetVConnection.cc:510
#3 0x00689142 in write_to_net_io (nh=0x729a2c10,
vc=0x7fffec19e580, thread=0x7299f010)
at ../../../../iocore/net/UnixNetVConnection.cc:374
#4 0x0067eb63 in NetHandler::mainNetEvent (this=0x729a2c10,
event=value optimized out,
e=value optimized out) at ../../../../iocore/net/UnixNet.cc:400
#5 0x006ab89f in handleEvent (this=0x7299f010, e=0x1013d20,
calling_code=5)
at ../../../../iocore/eventsystem/I_Continuation.h:146
#6 EThread::process_event (this=0x7299f010, e=0x1013d20, calling_code=5)
at ../../../../iocore/eventsystem/UnixEThread.cc:145
#7 0x006ac243 in EThread::execute (this=0x7299f010) at
../../../../iocore/eventsystem/UnixEThread.cc:269
#8 0x006aac4a in spawn_thread_internal (a=0xfe8cf0) at
../../../../iocore/eventsystem/Thread.cc:88
#9 0x7615a9d1 in start_thread (arg=0x7289d700) at
pthread_create.c:301
#10 0x751b1b6d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
{code}
The only thing I did was to enable the verify feature:
{code}
CONFIG proxy.config.ssl.client.verify.server INT 1
CONFIG proxy.config.ssl.client.cert.filename STRING
/etc/pki/tls/certs/ca-bundle.crt
{code}
Is it possible that this verify.server feature does not do what it sounds like
it should?
ATS does not verify server certificate
--
Key: TS-346
URL: https://issues.apache.org/jira/browse/TS-346
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: vijaya bhaskar mamidi
Priority: Critical
Labels: A
Fix For: 5.2.0
ATS does not verify the certificates correctly.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-346) ATS does not verify server certificate
[
https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911794#comment-13911794
]
Leif Hedstrom commented on TS-346:
--
The docs clearly indicates this is the option we'd want to use:
{code}
.. ts:cv:: CONFIG proxy.config.ssl.client.verify.server INT 0
Configures Traffic Server to verify the origin server certificate
with the Certificate Authority (CA).
{code}
ATS does not verify server certificate
--
Key: TS-346
URL: https://issues.apache.org/jira/browse/TS-346
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: vijaya bhaskar mamidi
Priority: Critical
Labels: A
Fix For: 5.2.0
ATS does not verify the certificates correctly.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (TS-346) ATS does not verify server certificate
[
https://issues.apache.org/jira/browse/TS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911790#comment-13911790
]
Leif Hedstrom edited comment on TS-346 at 2/25/14 5:58 PM:
---
Hmmm, I tested this again (same setup, enable verify, and provide the CA that
comes with Fedora), I get a different crash now:
{code}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7289d700 (LWP 1762)]
SSL_connect (s=0x0) at ssl_lib.c:945
945 if (s-handshake_func == 0)
Missing separate debuginfos, use: debuginfo-install tcl-8.5.7-6.el6.x86_64
(gdb) bt
#0 SSL_connect (s=0x0) at ssl_lib.c:945
#1 0x006774c8 in SSLNetVConnection::sslClientHandShakeEvent
(this=0x7fffec19e580, err=@0x7289cc5c)
at ../../../../iocore/net/SSLNetVConnection.cc:611
#2 0x00679739 in SSLNetVConnection::sslStartHandShake
(this=0x7fffec19e580, event=value optimized out,
err=@0x7289cc5c) at ../../../../iocore/net/SSLNetVConnection.cc:510
#3 0x00689142 in write_to_net_io (nh=0x729a2c10,
vc=0x7fffec19e580, thread=0x7299f010)
at ../../../../iocore/net/UnixNetVConnection.cc:374
#4 0x0067eb63 in NetHandler::mainNetEvent (this=0x729a2c10,
event=value optimized out,
e=value optimized out) at ../../../../iocore/net/UnixNet.cc:400
#5 0x006ab89f in handleEvent (this=0x7299f010, e=0x1013d20,
calling_code=5)
at ../../../../iocore/eventsystem/I_Continuation.h:146
#6 EThread::process_event (this=0x7299f010, e=0x1013d20, calling_code=5)
at ../../../../iocore/eventsystem/UnixEThread.cc:145
#7 0x006ac243 in EThread::execute (this=0x7299f010) at
../../../../iocore/eventsystem/UnixEThread.cc:269
#8 0x006aac4a in spawn_thread_internal (a=0xfe8cf0) at
../../../../iocore/eventsystem/Thread.cc:88
#9 0x7615a9d1 in start_thread (arg=0x7289d700) at
pthread_create.c:301
#10 0x751b1b6d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) frame 1
#1 0x006774c8 in SSLNetVConnection::sslClientHandShakeEvent
(this=0x7fffec19e580, err=@0x7289cc5c)
at ../../../../iocore/net/SSLNetVConnection.cc:611
warning: Source file is more recent than executable.
611 ret = SSL_connect(ssl);
(gdb) print ssl
$1 = (SSL *) 0x0
{code}
The only thing I did was to enable the verify feature:
{code}
CONFIG proxy.config.ssl.client.verify.server INT 1
CONFIG proxy.config.ssl.client.cert.filename STRING
/etc/pki/tls/certs/ca-bundle.crt
{code}
Is it possible that this verify.server feature does not do what it sounds like
it should?
was (Author: zwoop):
Hmmm, I tested this again (same setup, enable verify, and provide the CA that
comes with Fedora), I get a different crash now:
{code}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7289d700 (LWP 1762)]
SSL_connect (s=0x0) at ssl_lib.c:945
945 if (s-handshake_func == 0)
Missing separate debuginfos, use: debuginfo-install tcl-8.5.7-6.el6.x86_64
(gdb) bt
#0 SSL_connect (s=0x0) at ssl_lib.c:945
#1 0x006774c8 in SSLNetVConnection::sslClientHandShakeEvent
(this=0x7fffec19e580, err=@0x7289cc5c)
at ../../../../iocore/net/SSLNetVConnection.cc:611
#2 0x00679739 in SSLNetVConnection::sslStartHandShake
(this=0x7fffec19e580, event=value optimized out,
err=@0x7289cc5c) at ../../../../iocore/net/SSLNetVConnection.cc:510
#3 0x00689142 in write_to_net_io (nh=0x729a2c10,
vc=0x7fffec19e580, thread=0x7299f010)
at ../../../../iocore/net/UnixNetVConnection.cc:374
#4 0x0067eb63 in NetHandler::mainNetEvent (this=0x729a2c10,
event=value optimized out,
e=value optimized out) at ../../../../iocore/net/UnixNet.cc:400
#5 0x006ab89f in handleEvent (this=0x7299f010, e=0x1013d20,
calling_code=5)
at ../../../../iocore/eventsystem/I_Continuation.h:146
#6 EThread::process_event (this=0x7299f010, e=0x1013d20, calling_code=5)
at ../../../../iocore/eventsystem/UnixEThread.cc:145
#7 0x006ac243 in EThread::execute (this=0x7299f010) at
../../../../iocore/eventsystem/UnixEThread.cc:269
#8 0x006aac4a in spawn_thread_internal (a=0xfe8cf0) at
../../../../iocore/eventsystem/Thread.cc:88
#9 0x7615a9d1 in start_thread (arg=0x7289d700) at
pthread_create.c:301
#10 0x751b1b6d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
{code}
The only thing I did was to enable the verify feature:
{code}
CONFIG proxy.config.ssl.client.verify.server INT 1
CONFIG proxy.config.ssl.client.cert.filename STRING
/etc/pki/tls/certs/ca-bundle.crt
{code}
Is it possible that this verify.server feature does not do what it sounds like
it should?
ATS does not verify server certificate
--
Key: TS-346
URL:
[jira] [Resolved] (TS-2560) regex_remap lowercase substitutions is not being initialized in the construtor
[ https://issues.apache.org/jira/browse/TS-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-2560. Resolution: Fixed Committed the fix to the 5.0.0 release regex_remap lowercase substitutions is not being initialized in the construtor -- Key: TS-2560 URL: https://issues.apache.org/jira/browse/TS-2560 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 Report of this being turned on sometimes and having to set the option off in the config to make sure it is set to false. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2589) Headers delayed until the origin server starts sending content
[ https://issues.apache.org/jira/browse/TS-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911888#comment-13911888 ] ASF GitHub Bot commented on TS-2589: GitHub user jablko opened a pull request: https://github.com/apache/trafficserver/pull/49 TS-2589 Don't hold up the response until the server starts sending conte... ...nt You can merge this pull request into a Git repository by running: $ git pull https://github.com/jablko/trafficserver TS-2589 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/49.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #49 commit c42e983b9a2cd4ed33d37f18b46a4df997f0c4b8 Author: Jack Bates j...@nottheoilrig.com Date: 2014-02-25T18:31:35Z TS-2589 Don't hold up the response until the server starts sending content Headers delayed until the origin server starts sending content -- Key: TS-2589 URL: https://issues.apache.org/jira/browse/TS-2589 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates If there is a transform (for example a null transform) then the response headers aren't forwarded until the origin server starts sending content. Normally (without a transform) the headers are forwarded as soon as they are done, whether content is available yet or not. The headers are sent when the transform calls TSVConnWrite() and the transform is called at the end of the headers/start of the content. But it's not called if the available content is empty. A possible fix is to call the transform at the start of the content whether content is available yet or not. This doesn't affect a buffered transform which can still delay and update the headers until it calls TSVConnWrite() -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-727) Do we need support for streams partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-727: - Assignee: Alan M. Carroll Do we need support for streams partitions? Key: TS-727 URL: https://issues.apache.org/jira/browse/TS-727 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.0.0 There's code in the cache related to MIXT streams volumes (caches). Since we don't support streams, I'm thinking this code could be removed? Or alternatively, we should expose APIs so that someone writing a plugin and wish to store a different protocol (e.g. QT) can register this media type with the API and core. The idea being that the core only contains protocols that are in the core, but expose the cache core so that plugins can take advantage of it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-727) Do we need support for streams partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912040#comment-13912040 ] Leif Hedstrom commented on TS-727: -- [~amc] What do you think about this? Can we safely clean this out at a later time ? Is there even a reason to have these old MIXT types ? Should we just leave it as is ? Please asses, and move it out to 5.1, 6.0 or sometimes if appropriate. Or close as Won't Fix. Do we need support for streams partitions? Key: TS-727 URL: https://issues.apache.org/jira/browse/TS-727 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.0.0 There's code in the cache related to MIXT streams volumes (caches). Since we don't support streams, I'm thinking this code could be removed? Or alternatively, we should expose APIs so that someone writing a plugin and wish to store a different protocol (e.g. QT) can register this media type with the API and core. The idea being that the core only contains protocols that are in the core, but expose the cache core so that plugins can take advantage of it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-1429) Log collation of custom xml logs failing
[
https://issues.apache.org/jira/browse/TS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1429.
---
Resolution: Invalid
Fix Version/s: (was: 5.0.0)
I'm going to close this as invalid for now. Please reopen of current master, or
v4.2.0 experiences this problem still.
Log collation of custom xml logs failing
Key: TS-1429
URL: https://issues.apache.org/jira/browse/TS-1429
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: Linux
Reporter: Dan Morgan
When configuring logs_xml.config to send to a collation host with the
CollationHosts entry, we start to get these errors in traffic.out:
NOTE: [log-coll] send-queue full; orphaning logs [192.168.57.248:8085]
NOTE: [log-coll] send-queue clear; resuming collation [192.168.57.248:8085]
thousands of them.
It looks like there used to be a config value called:
collation_max_send_buffers that has been removed, but there's still code in
LogCollationClientSM.cc that references that value (which appears to now be
zero). Line 185 looks like:
if (m_buffer_send_list-get_size() =
Log::config-collation_max_send_buffers) {
Debug(log-coll, [%d]client::send - m_flow = DENY, m_id);
Note([log-coll] send-queue full; orphaning logs
[%s:%u], m_log_host-ip_addr().toString(ipb, sizeof(ipb)),
m_log_host-port());
m_flow = LOG_COLL_FLOW_DENY;
}
but since collation_max_send_buffers is zero, it always goes into that if
block.
Just as a note as well, issue TS-1299
(https://issues.apache.org/jira/browse/TS-1299) which has a patch for 3.1.4,
never made it into 3.2 (looks like it was done on the same day as 3.2 was
released).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (TS-1933) Uninformative warnings from traffic_manager on startup
[
https://issues.apache.org/jira/browse/TS-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1933:
-
Assignee: Leif Hedstrom
Uninformative warnings from traffic_manager on startup
--
Key: TS-1933
URL: https://issues.apache.org/jira/browse/TS-1933
Project: Traffic Server
Issue Type: Bug
Components: Management
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
During startup, traffic_manager always seems to produce these errors:
{code}
[Jun 1 14:59:46.577] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
Cleaning up and reissuing signal #2
[Jun 1 14:59:46.578] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: [TrafficManager] ==
signal #2
[Jun 1 14:59:46.607] Manager {0x7f9690c497e0} ERROR: (last system error 2:
No such file or directory)
{code}
They seem harmless, but annoying.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2120) stale_while_revalidate plugin does not build right now
[
https://issues.apache.org/jira/browse/TS-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912057#comment-13912057
]
Leif Hedstrom commented on TS-2120:
---
Phil: Shouldn't we just nuke this one ?
stale_while_revalidate plugin does not build right now
--
Key: TS-2120
URL: https://issues.apache.org/jira/browse/TS-2120
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.0.0
but considering that it's still using the old {{INK*}} API, oh, well...
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2218) create a standard way of getting the plugin configuration directory
[ https://issues.apache.org/jira/browse/TS-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2218: -- Assignee: Bryan Call create a standard way of getting the plugin configuration directory --- Key: TS-2218 URL: https://issues.apache.org/jira/browse/TS-2218 Project: Traffic Server Issue Type: Improvement Components: Configuration, Plugins Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 Currently some plugins use TSPluginDirGet() (/usr/local/libexec/trafficserver) and some have hard coded paths for getting the directory where the config files are set. I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in config.layout and is /usr/local/etc by default) as the default base directory for the plugin configuration. Under this directory people will have their config file or a sub directory if there are a lot of config files for a plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/) There will be an API to get the plugin config directory called TSPluginConfigDir() and this will by default pass back sysconfdir/trafficserver/plugins/. All plugins will use this API to get the configuration directory. There will also be a records.config option to override the default plugin config directory. This option will be called proxy.config.plugin.plugin_config_dir. This option will be set to NULL by default and the API will assume sysconfdir/trafficsever/plugins by default. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2218) create a standard way of getting the plugin configuration directory
[ https://issues.apache.org/jira/browse/TS-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912062#comment-13912062 ] Leif Hedstrom commented on TS-2218: --- So, this already exists, sort of, with TSConfigDirGet(). Do we still want to create an additional configuration area as proposed here ? In either case, I think TSConfigDirGet() should be retained. [~bcall] What do you think? I'm leaning towards just using TSConfigDirGet(), which gives the same config directory as the rest of ATS. create a standard way of getting the plugin configuration directory --- Key: TS-2218 URL: https://issues.apache.org/jira/browse/TS-2218 Project: Traffic Server Issue Type: Improvement Components: Configuration, Plugins Reporter: Bryan Call Fix For: 5.0.0 Currently some plugins use TSPluginDirGet() (/usr/local/libexec/trafficserver) and some have hard coded paths for getting the directory where the config files are set. I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in config.layout and is /usr/local/etc by default) as the default base directory for the plugin configuration. Under this directory people will have their config file or a sub directory if there are a lot of config files for a plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/) There will be an API to get the plugin config directory called TSPluginConfigDir() and this will by default pass back sysconfdir/trafficserver/plugins/. All plugins will use this API to get the configuration directory. There will also be a records.config option to override the default plugin config directory. This option will be called proxy.config.plugin.plugin_config_dir. This option will be set to NULL by default and the API will assume sysconfdir/trafficsever/plugins by default. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2218) create a standard way of getting the plugin configuration directory
[ https://issues.apache.org/jira/browse/TS-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912063#comment-13912063 ] Leif Hedstrom commented on TS-2218: --- Assigning to Bryan for evaluation. create a standard way of getting the plugin configuration directory --- Key: TS-2218 URL: https://issues.apache.org/jira/browse/TS-2218 Project: Traffic Server Issue Type: Improvement Components: Configuration, Plugins Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 Currently some plugins use TSPluginDirGet() (/usr/local/libexec/trafficserver) and some have hard coded paths for getting the directory where the config files are set. I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in config.layout and is /usr/local/etc by default) as the default base directory for the plugin configuration. Under this directory people will have their config file or a sub directory if there are a lot of config files for a plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/) There will be an API to get the plugin config directory called TSPluginConfigDir() and this will by default pass back sysconfdir/trafficserver/plugins/. All plugins will use this API to get the configuration directory. There will also be a records.config option to override the default plugin config directory. This option will be called proxy.config.plugin.plugin_config_dir. This option will be set to NULL by default and the API will assume sysconfdir/trafficsever/plugins by default. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (TS-2236) fabricate_with_old_api adds zero byte at the end of the response body
[ https://issues.apache.org/jira/browse/TS-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2236: - Assignee: Leif Hedstrom fabricate_with_old_api adds zero byte at the end of the response body - Key: TS-2236 URL: https://issues.apache.org/jira/browse/TS-2236 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: portl4t Assignee: Leif Hedstrom Fix For: 5.0.0 When ts decides to response error to ua, fabricate_with_old_api(...) will be called, and sometimes internal_msg_buffer_size will be set as strlen(internal_msg_buffer) + 1, including the last zero byte, so the client will receive a response which has a zero byte at the end of the body, should we remove the last zero byte? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2244) remove legacy proxy.config.log.search_log_enabled feature
[
https://issues.apache.org/jira/browse/TS-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2244:
--
Fix Version/s: (was: 5.0.0)
6.0.0
I'm moving this out for 6.0.0, but definitely move it back to v5.0.0 if this
will get modified / removed for this release.
remove legacy proxy.config.log.search_log_enabled feature
-
Key: TS-2244
URL: https://issues.apache.org/jira/browse/TS-2244
Project: Traffic Server
Issue Type: Bug
Components: Cleanup, Logging
Reporter: James Peach
Fix For: 6.0.0
While analyzing logging code, I came across the
{{proxy.config.log.search_log_enabled}} setting. This enabled a hard-coded
XML custom log format that may have been used to drive an Inktomi appliance
feature.
This has never been documented and is not generally useful to modern Traffic
Server deployments. We should remove it.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager
[ https://issues.apache.org/jira/browse/TS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912069#comment-13912069 ] Leif Hedstrom commented on TS-2268: --- Uri, is this going into v5.0.0 ? Add support for opening protocol traffic sockets through the traffic_manager Key: TS-2268 URL: https://issues.apache.org/jira/browse/TS-2268 Project: Traffic Server Issue Type: Improvement Components: Plugins, TS API Reporter: Uri Shachar Assignee: Uri Shachar Labels: Crash Fix For: 5.0.0 Add a TSNetAcceptNamedDescriptor(contp, char *) function to allow a protocol plugin to set a callback for accepting new connections on a socket opened by the traffic_manager (that's defined like 2345:plugin:name=myname in the server_ports configuration). This has three advantages on opening a socket using TSNetAccept: 1) If the traffic_server crashes and restarts, new connections won't be rejected while we recover - This is the main selling point of the new API. 2) Support for all port configuration flags (Which also exists when using TSPortDescriptorAccept) 3) Allow for a single point of configuration for all ATS ports -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (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 resolved TS-2395. --- Resolution: Cannot Reproduce Fix Version/s: (was: 5.0.0) Carlin: I'm going to close this for now, please reopen if you can reproduce this again. 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 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.5#6160)
[jira] [Work started] (TS-2568) body_factory's access#redirect_url uses questionable English
[
https://issues.apache.org/jira/browse/TS-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-2568 started by Leif Hedstrom.
body_factory's access#redirect_url uses questionable English
Key: TS-2568
URL: https://issues.apache.org/jira/browse/TS-2568
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Assignee: Leif Hedstrom
Fix For: 5.0.0
from {{{proxy/config/body_factory/default/access#redirect_url}}
{code}
BPlease wait while u r redirected to another page./B
{code}
I think we can do better than that.
Btw, I haven't reviewed all pages yet, perhaps there are other candidates.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-2568) body_factory's access#redirect_url uses questionable English
[
https://issues.apache.org/jira/browse/TS-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2568.
---
Resolution: Fixed
body_factory's access#redirect_url uses questionable English
Key: TS-2568
URL: https://issues.apache.org/jira/browse/TS-2568
Project: Traffic Server
Issue Type: Bug
Reporter: Igor Galić
Assignee: Leif Hedstrom
Fix For: 5.0.0
from {{{proxy/config/body_factory/default/access#redirect_url}}
{code}
BPlease wait while u r redirected to another page./B
{code}
I think we can do better than that.
Btw, I haven't reviewed all pages yet, perhaps there are other candidates.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2472) use boost to check if C++11 shared_ptr is available
[ https://issues.apache.org/jira/browse/TS-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912138#comment-13912138 ] Leif Hedstrom commented on TS-2472: --- [~briang] Do we still need this? use boost to check if C++11 shared_ptr is available --- Key: TS-2472 URL: https://issues.apache.org/jira/browse/TS-2472 Project: Traffic Server Issue Type: Improvement Components: Build, TS API Reporter: Radim Kolar Assignee: Brian Geffon Fix For: 5.0.0 Attachments: patch-sharedptr Using boost C++ feature check macros enhances portability. Now it compiles with clang. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-727) Do we need support for streams partitions?
[ https://issues.apache.org/jira/browse/TS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-727: - Component/s: Cache Do we need support for streams partitions? Key: TS-727 URL: https://issues.apache.org/jira/browse/TS-727 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 5.0.0 There's code in the cache related to MIXT streams volumes (caches). Since we don't support streams, I'm thinking this code could be removed? Or alternatively, we should expose APIs so that someone writing a plugin and wish to store a different protocol (e.g. QT) can register this media type with the API and core. The idea being that the core only contains protocols that are in the core, but expose the cache core so that plugins can take advantage of it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2253: -- Component/s: Core PluginVC::process_close Segmentation fault --- Key: TS-2253 URL: https://issues.apache.org/jira/browse/TS-2253 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.0.1 Reporter: bettydramit Assignee: weijin Fix For: 5.0.0 Attachments: 4.0.1.patch, TS-2253.wj.diff Env: centos 6 x86_64 ats 4.0.1 [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] [0x2b7b3e825ac0] gdb info Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. done. Loaded symbols for /lib64/libnss_dns-2.12.so Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. Program terminated with signal 11, Segmentation fault. #0 0x2ac40034ed80 in ?? () Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 (gdb) where #0 0x2ac40034ed80 in ?? () #1 0x004d1ef2 in PluginVC::process_close() () #2 0x004d2938 in PluginVC::main_handler(int, void*) () #3 0x006a372f in EThread::process_event(Event*, int) () #4 0x006a42ab in EThread::execute() () #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2120) stale_while_revalidate plugin does not build right now
[
https://issues.apache.org/jira/browse/TS-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2120:
--
Component/s: Plugins
stale_while_revalidate plugin does not build right now
--
Key: TS-2120
URL: https://issues.apache.org/jira/browse/TS-2120
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Igor Galić
Assignee: Phil Sorber
Fix For: 5.0.0
but considering that it's still using the old {{INK*}} API, oh, well...
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912149#comment-13912149 ] Leif Hedstrom commented on TS-2253: --- [~taorui] Any update on this ? PluginVC::process_close Segmentation fault --- Key: TS-2253 URL: https://issues.apache.org/jira/browse/TS-2253 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.0.1 Reporter: bettydramit Assignee: weijin Fix For: 5.0.0 Attachments: 4.0.1.patch, TS-2253.wj.diff Env: centos 6 x86_64 ats 4.0.1 [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] [0x2b7b3e825ac0] gdb info Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. done. Loaded symbols for /lib64/libnss_dns-2.12.so Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. Program terminated with signal 11, Segmentation fault. #0 0x2ac40034ed80 in ?? () Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 (gdb) where #0 0x2ac40034ed80 in ?? () #1 0x004d1ef2 in PluginVC::process_close() () #2 0x004d2938 in PluginVC::main_handler(int, void*) () #3 0x006a372f in EThread::process_event(Event*, int) () #4 0x006a42ab in EThread::execute() () #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2585) add support for maintaining pristine_host_hdr or not in regex_remap
[ https://issues.apache.org/jira/browse/TS-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912145#comment-13912145 ] Bryan Call commented on TS-2585: From [~zwoop]: Let's add a generic interface to allow all overridable configs instead? Like how we do it in header_rewrite. add support for maintaining pristine_host_hdr or not in regex_remap --- Key: TS-2585 URL: https://issues.apache.org/jira/browse/TS-2585 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Ethan Lai Assignee: Bryan Call Priority: Minor Fix For: 5.0.0 Attachments: ts2585.diff Add the option @pristine_host_hdr=1 to regex_remap to maintain pristine_host_hdr or not -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2274) Better initial default configs
[ https://issues.apache.org/jira/browse/TS-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2274: -- Component/s: Configuration Better initial default configs -- Key: TS-2274 URL: https://issues.apache.org/jira/browse/TS-2274 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Miles Libbey Fix For: 5.0.0 Seems like there are several config values that are not very smart for the newbie user: - cache size: storage.config: var/trafficserver 256M - max object size (though, perhaps this is now unlimited) - read-while-write settings? - 4-5 volumes for the volume config? - CONFIG proxy.config.cache.ram_cache_cutoff INT 4194304 ? Adam Dace in https://cwiki.apache.org/confluence/display/TS/WebProxyCacheSetup suggested several others, but, it looks to me like the settings are very machine specific (eg, specific IP addresses) Others? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2332) Add Consistent Hash class to libts
[ https://issues.apache.org/jira/browse/TS-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2332: -- Component/s: Core Add Consistent Hash class to libts -- Key: TS-2332 URL: https://issues.apache.org/jira/browse/TS-2332 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Phil Sorber Assignee: Phil Sorber Fix For: 5.0.0 We may have a consistent hash implementation in the cluster code, but we don't have a general one available to libts. We need one to implement a consistent hash option for parent selection. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2433) Size threshold for SSL request
[ https://issues.apache.org/jira/browse/TS-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2433: -- Component/s: SSL Size threshold for SSL request -- Key: TS-2433 URL: https://issues.apache.org/jira/browse/TS-2433 Project: Traffic Server Issue Type: Task Components: SSL Reporter: Wei Sun Assignee: Wei Sun Labels: Review Fix For: 5.0.0 Attachments: TS-2433.diff A size threshold is expected for client request over SSL, if the max requested data(SSL_read) exceeds the threshold, close the connection. Default: no size limitation. We have this use case when using stunnel, expect to have the same functionality in ATS. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2462) FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation which is deleted`
[
https://issues.apache.org/jira/browse/TS-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2462:
--
Component/s: HTTP
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
Key: TS-2462
URL: https://issues.apache.org/jira/browse/TS-2462
Project: Traffic Server
Issue Type: Bug
Components: HTTP, TS API
Reporter: bettydramit
Fix For: 5.0.0
4.0.1 -4.1.2
{code}
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.4(+0x141e8)[0x2b716e8ac1e8]
/usr/lib64/trafficserver/libtsutil.so.4(+0x128df)[0x2b716e8aa8df]
/usr/bin/traffic_server[0x4af6b4]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4d08b5]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4d120a]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x2c3)[0x4d2123]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a37ff]
/usr/bin/traffic_server(EThread::execute()+0x6e3)[0x6a4423]
/usr/bin/traffic_server[0x6a269a]
/lib64/libpthread.so.0(+0x7851)[0x2b7170708851]
/lib64/libc.so.6(clone+0x6d)[0x2b71713ac90d]
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2462) FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation which is deleted`
[
https://issues.apache.org/jira/browse/TS-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2462:
--
Component/s: TS API
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
Key: TS-2462
URL: https://issues.apache.org/jira/browse/TS-2462
Project: Traffic Server
Issue Type: Bug
Components: HTTP, TS API
Reporter: bettydramit
Fix For: 5.0.0
4.0.1 -4.1.2
{code}
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.4(+0x141e8)[0x2b716e8ac1e8]
/usr/lib64/trafficserver/libtsutil.so.4(+0x128df)[0x2b716e8aa8df]
/usr/bin/traffic_server[0x4af6b4]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4d08b5]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4d120a]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x2c3)[0x4d2123]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a37ff]
/usr/bin/traffic_server(EThread::execute()+0x6e3)[0x6a4423]
/usr/bin/traffic_server[0x6a269a]
/lib64/libpthread.so.0(+0x7851)[0x2b7170708851]
/lib64/libc.so.6(clone+0x6d)[0x2b71713ac90d]
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2494: -- Component/s: HTTP ts crash if negative_revalidating_enabled when the os is down - Key: TS-2494 URL: https://issues.apache.org/jira/browse/TS-2494 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.5, 4.0.2, 4.1.2 Reporter: weijin Assignee: weijin Priority: Critical Fix For: 5.0.0 Attachments: TS-2494.diff -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2494: -- Labels: crash (was: ) ts crash if negative_revalidating_enabled when the os is down - Key: TS-2494 URL: https://issues.apache.org/jira/browse/TS-2494 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.5, 4.0.2, 4.1.2 Reporter: weijin Assignee: weijin Priority: Critical Labels: crash Fix For: 5.0.0 Attachments: TS-2494.diff -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2494) ts crash if negative_revalidating_enabled when the os is down
[ https://issues.apache.org/jira/browse/TS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912166#comment-13912166 ] Leif Hedstrom commented on TS-2494: --- [~taorui] Should we land this patch ? ts crash if negative_revalidating_enabled when the os is down - Key: TS-2494 URL: https://issues.apache.org/jira/browse/TS-2494 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.5, 4.0.2, 4.1.2 Reporter: weijin Assignee: weijin Priority: Critical Labels: crash Fix For: 5.0.0 Attachments: TS-2494.diff -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2584) failed assert transforming and caching negative response
[
https://issues.apache.org/jira/browse/TS-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2584:
--
Component/s: HTTP
failed assert transforming and caching negative response
Key: TS-2584
URL: https://issues.apache.org/jira/browse/TS-2584
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Jack Bates
Labels: Review
Fix For: 5.0.0
If negative caching is enabled and you transform a negative response (for
example a null transform) there is a failed assert in
HttpTransact::set_headers_for_cache_write()
{noformat}
FATAL: HttpTransact.cc:4811: failed assert
`cache_info-response_get()-valid()`
proxy/.libs/lt-traffic_server - STACK TRACE:
lib/ts/.libs/libtsutil.so.5(ink_fatal_die+0x0)[0xb77a6445]
lib/ts/.libs/libtsutil.so.5(+0x22269)[0xb77a5269]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0x1da)[0x81c0ae6]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x272)[0x81c0576]
proxy/.libs/lt-traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x78)[0x81a4b3e]
proxy/.libs/lt-traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0x196)[0x81926b0]
proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2df)[0x81969b5]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x27f)[0x815d81b]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x104)[0x8300692]
proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0xd6)[0x8300916]
proxy/.libs/lt-traffic_server[0x82ff569]
/lib/i686/cmov/libpthread.so.0(+0x5955)[0xb7467955]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb717f1de]
Aborted (core dumped)
{noformat}
HttpTransact::handle_transform_ready() passes s-cache_info.transform_store
to HttpTransact::set_headers_for_cache_write()
The -valid() test at the top of HttpTransact::set_headers_for_cache_write()
fails so -create() gets called.
{code}
if (!cache_info-valid()) {
cache_info-create();
}
{code}
(s-cache_info.transform_store-m_alt is NULL. I didn't look into why this
is, is it expected?)
Because s-negative_caching is true, cache_info-response_set(response)
doesn't get called, instead the assert fails.
{code}
if (!s-negative_caching)
cache_info-response_set(response);
else {
ink_assert(cache_info-response_get()-valid());
}
{code}
Assuming the cache_info-valid() test can fail and s-negative_caching can be
true at the same time, one possible solution is to fix the logic so
cache_info-response_set(response) gets called?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2564:
--
Labels: crash (was: )
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Priority: Blocker
Labels: crash
Fix For: 4.2.0
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-852) hostdb and dns system hangup
[
https://issues.apache.org/jira/browse/TS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912177#comment-13912177
]
Leif Hedstrom commented on TS-852:
--
Phil?
hostdb and dns system hangup
Key: TS-852
URL: https://issues.apache.org/jira/browse/TS-852
Project: Traffic Server
Issue Type: Bug
Components: Core, DNS
Affects Versions: 3.1.0
Reporter: Zhao Yongming
Assignee: Phil Sorber
Priority: Minor
Labels: dns, hostdb
Fix For: 3.1.0, 5.0.0
Attachments: TS-852.patch
in my testing, all request that need go OS, fails with 30s timeout, and the
slow query shows data from dns missed:
{code}
[Jun 22 15:33:47.183] Server {1106880832} ERROR: [8122411] Slow Request: url:
http://download.im.alisoft.com/aliim/AliIM6/update/packages//2011-5-4-10-10-40/0/modulesproxy/8203.xml.wwzip
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.667 sm_finish: 30.667
[Jun 22 15:33:47.220] Server {1099663680} ERROR: [8122422] Slow Request: url:
http://img.uu1001.cn/materials/original/2010-11-22/22-48/a302876929a9c40a8272ac439a16ad25e74edf71.png
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.318 sm_finish: 30.318
[Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122421] Slow Request: url:
http://img02.taobaocdn.com/bao/uploaded/i2/T1mp8QXopdXXblNIZ6_061203.jpg_b.jpg
status: 0 unique id: bytes: 0 fd: 0 client state: 6 server state: 0
ua_begin: 0.000 ua_read_header_done: 0.000 cache_open_read_begin: 0.000
cache_open_read_end: 0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000
server_connect: -1.000 server_first_read: -1.000 server_read_header_done:
-1.000 server_close: -1.000 ua_close: 30.597 sm_finish: 30.597
[Jun 22 15:33:47.441] Server {1098611008} ERROR: [8122409] Slow Request: url:
http://img04.taobaocdn.com/tps/i4/T1EM9gXltt-440-135.jpg status: 0
unique id: bytes: 0 fd: 0 client state: 6 server state: 0 ua_begin: 0.000
ua_read_header_done: 0.000 cache_open_read_begin: 0.000 cache_open_read_end:
0.000 dns_lookup_begin: 0.000 dns_lookup_end: -1.000 server_connect: -1.000
server_first_read: -1.000 server_read_header_done: -1.000 server_close:
-1.000 ua_close: 30.948 sm_finish: 30.948
{code}
all http SM show from {http} in DNS_LOOKUP
and traffic.out show nothing with error, when I enable debug on
hostdb.*|dns.*:
{code}
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) probe
img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) timeout 64204
1308663404 300
[Jun 22 15:27:42.391] Server {1108986176} DEBUG: (hostdb) delaying force 0
answer for img03.taobaocdn.com [timeout 0]
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) probe
img03.taobaocdn.com DB357D60B8247DC7 1 [ignore_timeout = 0]
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) timeout 64204
1308663404 300
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) DNS
img03.taobaocdn.com
[Jun 22 15:27:42.411] Server {1108986176} DEBUG: (hostdb) enqueuing
additional request
[Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) probe 127.0.0.1
E9B7563422C93608 1 [ignore_timeout = 0]
[Jun 22 15:27:42.416] Server {47177168876656} DEBUG: (hostdb) immediate
answer for 127.0.0.1
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) probe
img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) timeout 64281
1308663327 300
[Jun 22 15:27:42.422] Server {1098611008} DEBUG: (hostdb) delaying force 0
answer for img08.taobaocdn.com [timeout 0]
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) probe
img08.taobaocdn.com 945198AE9AE37481 1 [ignore_timeout = 0]
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) timeout 64281
1308663327 300
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) DNS
img08.taobaocdn.com
[Jun 22 15:27:42.441] Server {1098611008} DEBUG: (hostdb) enqueuing
additional request
[Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb) probe 127.0.0.1
E9B7563422C93608 1 [ignore_timeout = 0]
[Jun 22 15:27:42.470] Server {1099663680} DEBUG: (hostdb) immediate
[jira] [Updated] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-935: - Labels: API (was: ) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT Key: TS-935 URL: https://issues.apache.org/jira/browse/TS-935 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Brian Geffon Labels: api-change Fix For: 5.0.0 When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon the fact that the API will decrement the event count for EVENT_INTERNAL or EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT because as of now doing so would cause m_event_count to become -1 or shouldn't these defined values be something different? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1015: -- Labels: API (was: ) TSEvent is widely declared as int - Key: TS-1015 URL: https://issues.apache.org/jira/browse/TS-1015 Project: Traffic Server Issue Type: Bug Components: Cleanup Reporter: Nick Kew Assignee: Igor Galić Priority: Minor Labels: api-change Fix For: 5.0.0 TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is declared as type int. This makes it harder to follow/debug using tools like *trace or gdb. This may usefully be fixed as and when people encounter instances of it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-935: - Labels: api-change (was: API) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT Key: TS-935 URL: https://issues.apache.org/jira/browse/TS-935 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Brian Geffon Labels: api-change Fix For: 5.0.0 When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon the fact that the API will decrement the event count for EVENT_INTERNAL or EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT because as of now doing so would cause m_event_count to become -1 or shouldn't these defined values be something different? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1033) Add some missing WKS's to HdrToken.
[ https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1033: -- Labels: (was: A) Add some missing WKS's to HdrToken. - Key: TS-1033 URL: https://issues.apache.org/jira/browse/TS-1033 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 And of course various other places (including InkAPI). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (TS-1486) drop solaris studio support
[ https://issues.apache.org/jira/browse/TS-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1486: - Assignee: Leif Hedstrom (was: Igor Galić) drop solaris studio support --- Key: TS-1486 URL: https://issues.apache.org/jira/browse/TS-1486 Project: Traffic Server Issue Type: Bug Components: Core, Portability Reporter: James Peach Assignee: Leif Hedstrom Fix For: 5.0.0 We should drop Solaris Studio support for the 3.4 release. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1015: -- Labels: api-change (was: API) TSEvent is widely declared as int - Key: TS-1015 URL: https://issues.apache.org/jira/browse/TS-1015 Project: Traffic Server Issue Type: Bug Components: Cleanup Reporter: Nick Kew Assignee: Igor Galić Priority: Minor Labels: api-change Fix For: 5.0.0 TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is declared as type int. This makes it harder to follow/debug using tools like *trace or gdb. This may usefully be fixed as and when people encounter instances of it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1509) Remove TS_PARSE_OK constant
[ https://issues.apache.org/jira/browse/TS-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1509: -- Labels: api-change (was: ) Remove TS_PARSE_OK constant --- Key: TS-1509 URL: https://issues.apache.org/jira/browse/TS-1509 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Priority: Minor Labels: api-change Fix For: 5.0.0 There's TS_PARSE_DONE and TS_PARSE_OK. Which one should a developer handle and what's the difference between? Well TS_PARSE_OK is never returned from TSHttpParseResp() so we should just remove it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1588) slow log should include client addr
[ https://issues.apache.org/jira/browse/TS-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1588: -- Assignee: Bryan Call slow log should include client addr --- Key: TS-1588 URL: https://issues.apache.org/jira/browse/TS-1588 Project: Traffic Server Issue Type: Improvement Components: HTTP, Logging Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: Bryan Call Fix For: 5.0.0 we should include client address in the slow query log, that may help us identify some client side issue just in case -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-1822) Do we still need proxy.config.system.mmap_max ?
[ https://issues.apache.org/jira/browse/TS-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912185#comment-13912185 ] Leif Hedstrom commented on TS-1822: --- [~jpe...@apache.org] What do we do with this ? [~zym] On your boxes, how many mmap areas does it use ? If this configuration is unrelated to how many mmap areas you can have, then how does it affect your system? Do we still need proxy.config.system.mmap_max ? --- Key: TS-1822 URL: https://issues.apache.org/jira/browse/TS-1822 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: James Peach Fix For: 5.0.0 A long time ago, we added proxy.config.system.mmap_max to let the traffic_server increase the max number of mmap segments that we want to use. We currently set this to 2MM. I'm wondering, do we really need this still ? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1833) Deprecate TSMimeHdrFieldValueStringInsert() (and family)
[ https://issues.apache.org/jira/browse/TS-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1833: -- Labels: api-change (was: ) Deprecate TSMimeHdrFieldValueStringInsert() (and family) Key: TS-1833 URL: https://issues.apache.org/jira/browse/TS-1833 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 5.0.0 It seems to be that TSMimeHdrFieldValueStringInsert() is really just a subset of TSMimeHdrFieldValueStringSet(). This just makes for confusing APIs, i.e. which one do I use when? The alternative would be to remove the idx argument to the TSMimeHdrFieldValueStringSet() method, but that would then break API and ABI compatibility. Also, as James found out, the docs are less than clear. Set() needs to be called with an idx of -1 for it to actually be a Set() operation. With idx =0, TSMimeHdrFieldValueStringSet() is actually identical to TSMimeHdrFieldValueStringInsert() -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-1996) Remove TSHttpTxnNewCacheLookupDo API
[ https://issues.apache.org/jira/browse/TS-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1996: -- Labels: api-change (was: A) Remove TSHttpTxnNewCacheLookupDo API Key: TS-1996 URL: https://issues.apache.org/jira/browse/TS-1996 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 5.0.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (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:all-tabpanel ] Leif Hedstrom updated TS-2210: -- Labels: Review api-change (was: Review) 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 Assignee: James Peach Labels: Review, api-change Fix For: 5.0.0 Attachments: 2210.diff, TS-2210-2.diff 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.5#6160)
[jira] [Updated] (TS-2110) Cleanup ts/experimental.h
[ https://issues.apache.org/jira/browse/TS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2110: -- Labels: api-change (was: ) Cleanup ts/experimental.h - Key: TS-2110 URL: https://issues.apache.org/jira/browse/TS-2110 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 5.0.0 We should go through the APIs in experimental.h, and do one of 1. Remove 2. Move to ts/ts.h.in 3. Leave as is, assuming it's still considered experimental. I know there are arguments for and against having an experimental.h include file. I guess I don't have a strong opinion, another solution is to simply keep everything in ts.h.in, but mark APIs that are experimental as such. I do believe having APIs in an experimental state has benefits (such as we can modify such APIs as we see fit, there is no ABI/API compatibility promise). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2218) create a standard way of getting the plugin configuration directory
[ https://issues.apache.org/jira/browse/TS-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2218: -- Labels: api-change (was: ) create a standard way of getting the plugin configuration directory --- Key: TS-2218 URL: https://issues.apache.org/jira/browse/TS-2218 Project: Traffic Server Issue Type: Improvement Components: Configuration, Plugins Reporter: Bryan Call Assignee: Bryan Call Labels: api-change Fix For: 5.0.0 Currently some plugins use TSPluginDirGet() (/usr/local/libexec/trafficserver) and some have hard coded paths for getting the directory where the config files are set. I propose using sysconfdir/trafficserver/plugins/ (sysconfdir is defined in config.layout and is /usr/local/etc by default) as the default base directory for the plugin configuration. Under this directory people will have their config file or a sub directory if there are a lot of config files for a plugin (e.g. sysconfdir/trafficserver/plugins/regex_remap/) There will be an API to get the plugin config directory called TSPluginConfigDir() and this will by default pass back sysconfdir/trafficserver/plugins/. All plugins will use this API to get the configuration directory. There will also be a records.config option to override the default plugin config directory. This option will be called proxy.config.plugin.plugin_config_dir. This option will be set to NULL by default and the API will assume sysconfdir/trafficsever/plugins by default. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager
[ https://issues.apache.org/jira/browse/TS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2268: -- Labels: api-change (was: Crash) Add support for opening protocol traffic sockets through the traffic_manager Key: TS-2268 URL: https://issues.apache.org/jira/browse/TS-2268 Project: Traffic Server Issue Type: Improvement Components: Plugins, TS API Reporter: Uri Shachar Assignee: Uri Shachar Labels: api-change Fix For: 5.0.0 Add a TSNetAcceptNamedDescriptor(contp, char *) function to allow a protocol plugin to set a callback for accepting new connections on a socket opened by the traffic_manager (that's defined like 2345:plugin:name=myname in the server_ports configuration). This has three advantages on opening a socket using TSNetAccept: 1) If the traffic_server crashes and restarts, new connections won't be rejected while we recover - This is the main selling point of the new API. 2) Support for all port configuration flags (Which also exists when using TSPortDescriptorAccept) 3) Allow for a single point of configuration for all ATS ports -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2312) API stable: move TS_HRTIME_* from experimental.h to ts.h
[ https://issues.apache.org/jira/browse/TS-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2312: -- Labels: api-change (was: ) API stable: move TS_HRTIME_* from experimental.h to ts.h Key: TS-2312 URL: https://issues.apache.org/jira/browse/TS-2312 Project: Traffic Server Issue Type: Improvement Components: TS API Affects Versions: 4.1.2 Reporter: Zhao Yongming Labels: api-change Fix For: 5.0.0 as wished from TS-2200 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2253) PluginVC::process_close Segmentation fault
[ https://issues.apache.org/jira/browse/TS-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2253: -- Labels: crash (was: ) PluginVC::process_close Segmentation fault --- Key: TS-2253 URL: https://issues.apache.org/jira/browse/TS-2253 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 4.0.1 Reporter: bettydramit Assignee: weijin Labels: crash Fix For: 5.0.0 Attachments: 4.0.1.patch, TS-2253.wj.diff Env: centos 6 x86_64 ats 4.0.1 [E. Mgmt] log == [TrafficManager] using root directory '/usr' [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b7b3a8a3500] [0x2b7b3e825ac0] gdb info Reading symbols from /lib64/libnss_dns-2.12.so...Reading symbols from /usr/lib/debug/lib64/libnss_dns-2.12.so.debug...done. done. Loaded symbols for /lib64/libnss_dns-2.12.so Core was generated by `/usr/bin/traffic_server -M --httpport 80:fd=7'. Program terminated with signal 11, Segmentation fault. #0 0x2ac40034ed80 in ?? () Missing separate debuginfos, use: debuginfo-install ts-4.0.1-9.el6.x86_64 (gdb) where #0 0x2ac40034ed80 in ?? () #1 0x004d1ef2 in PluginVC::process_close() () #2 0x004d2938 in PluginVC::main_handler(int, void*) () #3 0x006a372f in EThread::process_event(Event*, int) () #4 0x006a42ab in EThread::execute() () #5 0x004c59b4 in main () -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2319) Change default behavior for the various ignore-mismatch configs
[
https://issues.apache.org/jira/browse/TS-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912203#comment-13912203
]
ASF subversion and git services commented on TS-2319:
-
Commit 61e6dcd515bd519d485fc31666eaf6c09559418a in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=61e6dcd ]
TS-2319] Change default behavior for the various ignore-mismatch configs
Change default behavior for the various ignore-mismatch configs
---
Key: TS-2319
URL: https://issues.apache.org/jira/browse/TS-2319
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
We should consider making at least these behavior changes the default for
v5.0.x:
{code}
CONFIG proxy.config.http.cache.ignore_accept_language_mismatch INT 2
CONFIG proxy.config.http.cache.ignore_accept_encoding_mismatch INT 2
CONFIG proxy.config.http.cache.ignore_accept_charset_mismatch INT 2
{code}
Optionally, maybe even consider
{code}
CONFIG proxy.config.http.cache.ignore_accept_mismatch INT 2
{code}
I think there are valid use cases for the old behaviors (0 and 1), so we
should leave the configurations IMO.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (TS-2319) Change default behavior for the various ignore-mismatch configs
[
https://issues.apache.org/jira/browse/TS-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2319.
---
Resolution: Fixed
Change default behavior for the various ignore-mismatch configs
---
Key: TS-2319
URL: https://issues.apache.org/jira/browse/TS-2319
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 5.0.0
We should consider making at least these behavior changes the default for
v5.0.x:
{code}
CONFIG proxy.config.http.cache.ignore_accept_language_mismatch INT 2
CONFIG proxy.config.http.cache.ignore_accept_encoding_mismatch INT 2
CONFIG proxy.config.http.cache.ignore_accept_charset_mismatch INT 2
{code}
Optionally, maybe even consider
{code}
CONFIG proxy.config.http.cache.ignore_accept_mismatch INT 2
{code}
I think there are valid use cases for the old behaviors (0 and 1), so we
should leave the configurations IMO.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2357) Add option to cache POST requests
[ https://issues.apache.org/jira/browse/TS-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912217#comment-13912217 ] Leif Hedstrom commented on TS-2357: --- [~bcall] is this going into v5.0.0 ? Add option to cache POST requests - Key: TS-2357 URL: https://issues.apache.org/jira/browse/TS-2357 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 This feature was added to YTS after it was open sourced. Yahoo bug number: 2831983 This is the configuration option and it might be nice to keep it the same name for those that are migrating from YTS to ATS: CONFIG proxy.config.http.cache.cache_method_post INT 1 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2367: -- Assignee: Bryan Call Add OCSP (Online Certificate Status Protocol) Stapling Support --- Key: TS-2367 URL: https://issues.apache.org/jira/browse/TS-2367 Project: Traffic Server Issue Type: New Feature Components: HTTP, SSL Reporter: Bryan Call Assignee: Bryan Call Fix For: 5.0.0 RFC: http://tools.ietf.org/html/rfc6066 Overview: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling http://en.wikipedia.org/wiki/OCSP_stapling There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2349) move command-line tools to obvious places
[ https://issues.apache.org/jira/browse/TS-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912215#comment-13912215 ] Leif Hedstrom commented on TS-2349: --- [~jpe...@apache.org] Is this done ? move command-line tools to obvious places - Key: TS-2349 URL: https://issues.apache.org/jira/browse/TS-2349 Project: Traffic Server Issue Type: Bug Components: Cleanup, Core, Quality Reporter: James Peach Assignee: James Peach Fix For: 5.0.0 It's often difficult to figure out where the source for a given command-line tools lives. This makes it hard to navigate the source tree, but also hard to decouple the build dependencies. Moving these tools to an obvious source tree location is a small change that can help this. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2402) SSL v3 is disabled
[
https://issues.apache.org/jira/browse/TS-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912225#comment-13912225
]
Leif Hedstrom commented on TS-2402:
---
[~jpe...@apache.org] So should we close this as invalid ?
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: 5.0.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.5#6160)
[jira] [Commented] (TS-2391) Traffic Server tries to reverse resolve 127.0.0.1
[
https://issues.apache.org/jira/browse/TS-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912221#comment-13912221
]
Leif Hedstrom commented on TS-2391:
---
[~bcall]what should we do here?
Traffic Server tries to reverse resolve 127.0.0.1
-
Key: TS-2391
URL: https://issues.apache.org/jira/browse/TS-2391
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: David Carlin
Assignee: Bryan Call
Fix For: 5.0.0
We have a number of remaps using 127.0.0.1 for serving healthchecks. Bryan
Call noticed ATS seems to try and resolve 1.0.0.127.in-addr.arpa for every
one of the requests (there are a lot, sometimes hundreds per second).
Occasionally this process hangs; If I grep squid.blog for 127.0.0.1 I'll see
the healthcheck log entries flowing and then all of a sudden it'll stop
anywhere from 15-80 seconds. Then the backlog of healthchecks is cleared out
at once. 5-20 minutes later this process will recur.
From traffic.out with debug dns.*|hostdb.* - this occurs continuously.
Lookup for 1.0.0.127.in-addr.arpa fails (NXDOMAIN) and it doesn't get added
to HostDB.
Unsure if related, but TS-852 seemed similar.
{noformat}
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received query
type = 12, timeout = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) enqueing query
1.0.0.127.in-addr.arpa
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) adding first to
collapsing queue
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query
(qtype=12) for 1.0.0.127.in-addr.arpa to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname =
1.0.0.127.in-addr.arpa, id = 56887, nameserver = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent_one:
failover_number for resolver 0 is 1
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received packet
size = 109
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS
response code = 0
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 3
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 3 for
[1.0.0.127.in-addr.arpa]
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) send query
(qtype=12) for to fd 236
[Nov 24 20:40:46.619] Server {0x2b759c8953a0} DEBUG: (dns) sent qname = , id
= 4497, nameserver = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) sent_one:
failover_number for resolver 0 is 1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received packet
size = 92
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) primary DNS
response code = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) received rcode = 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) DNS error 0 for []
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) FAIL result for =
not found retry 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (dns) called back
continuation for
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 1]
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) failed for
127.0.0.1
[Nov 24 20:40:46.620] Server {0x2b759c8953a0} DEBUG: (hostdb) inserting for:
: (md5: aa30de0f80a82135) bucket: 1017 now: 1385325494 timeout: 0 ttl: 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe 127.0.0.1
9993e35a45b4be6a 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) immediate
answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.707] Server {0x2b759d74e700} DEBUG: (hostdb) delaying force
0 answer for 127.0.0.1
[Nov 24 20:40:46.707] Server {0x2b759c8953a0} DEBUG: (hostdb) probe
aa30de0f80a82135 1 [ignore_timeout = 0]
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) '' failed
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) fail timeout 0
[Nov 24 20:40:46.708] Server {0x2b759c8953a0} DEBUG: (hostdb) DNS IP 127.0.0.1
{noformat}
YTS doesn't have this issue:
{noformat}
bash-3.2# traffic_server -k
[Nov 24 20:18:11.941] {4146358528} STATUS: opened /home/y/logs/yts/diags.log
[Nov 24 20:18:11.959] Server {4146358528} DEBUG: (dns) ink_dns_init: called
with init_called = 0
[Nov 24 20:18:11.992] Server {4146358528} DEBUG:
[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-tabpanelfocusedCommentId=13912224#comment-13912224
]
Leif Hedstrom commented on TS-2400:
---
Can we get something committed here for v5.0.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ć
Assignee: 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.5#6160)
[jira] [Assigned] (TS-2405) Change the default for proxy.config.net.sock_option_flag_out to 1
[ https://issues.apache.org/jira/browse/TS-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2405: - Assignee: Leif Hedstrom (was: xiongzongtao) Change the default for proxy.config.net.sock_option_flag_out to 1 - Key: TS-2405 URL: https://issues.apache.org/jira/browse/TS-2405 Project: Traffic Server Issue Type: Bug Components: Configuration, HTTP Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: 5.0.0 TCP_NODELAY should be set on the outgoing socket. We see delays on POST requests. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-612) ATS does not allow password protected certificates
[
https://issues.apache.org/jira/browse/TS-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912230#comment-13912230
]
ASF subversion and git services commented on TS-612:
Commit e0c35aa8aad57ae473d02528c67f96da5b549b8c in trafficserver's branch
refs/heads/master from [~rwbarber2]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e0c35aa ]
TS-612: add support for SSL keys with passphrases
Add support for dialog settings in ssl_multicert.config to allow for
passphrase protected private keys.
ATS does not allow password protected certificates
--
Key: TS-612
URL: https://issues.apache.org/jira/browse/TS-612
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Affects Versions: 3.0.0
Environment: Any
Reporter: Igor Galić
Assignee: Ron Barber
Labels: Review
Fix For: 5.0.0
Create a (self-signed) certificate with a password that is non-empty. {cat
server.key server.crt server.pem} and configure it as
{CONFIG proxy.config.ssl.server.cert.filename STRING server.pem}
The result will be:
{noformat}
Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting
---
Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version:
Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31
2010 at 12:58:34)
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened
var/log/trafficserver/diags.log
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated
diags config
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
clustering disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no
cache disks specified in etc/trafficserver/storage.config: cache disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache
clustering disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING:
unable to open cache disk(s): Cache Disabled
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
ERROR: Cannot use server private key file.
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting
password:pem_lib.c:105:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password
read:pem_lib.c:406:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR:
SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM
lib:ssl_rsa.c:669:
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL
ERROR: Can't initialize the SSL library, disabling SSL termination!.
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging
initialized[7], logging_mode = 3
Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic
server running
{noformat}
A first -- ugly -- shot would be to at least have a password field in the
configuration.
In the end something taking the input of an external program or from a file
would be more desirable.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-382) socket option cleanup (and bug fixes)
[
https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912244#comment-13912244
]
James Peach commented on TS-382:
The right thing to do here is to parse supported socket option strings, e.g.:
{code}
CONFIG proxy.config.net.sock_option_flag_out STRING TCP_NODELAY TCP_QUICKACK
{code}
socket option cleanup (and bug fixes)
---
Key: TS-382
URL: https://issues.apache.org/jira/browse/TS-382
Project: Traffic Server
Issue Type: Bug
Components: Network
Reporter: Leif Hedstrom
Assignee: Alan M. Carroll
Fix For: 6.0.0
This is a bug moved from Y! Bugzilla, I'm posting the original bug
description and a few comments separately. Note that the bug description is
fairly limited, but while looking at this code, I noticed a lot of oddities
with the socket option support (lots of hardcoded stuff, and most of it is
not configurable).
Note that the original bug should have been fixed already in Apache TS, but
the other comments are still applicable.
From Bugzilla (posted by Leif):
We have two socket option config options in records.config:
proxy.config.net.sock_option_flag_in
proxy.config.net.sock_option_flag_out
With accept thread enabled, at least the _in option isn't honored. There are
possibly other cases in UnixNetAccept.cc
that we don't honor these flags either.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-382) socket option cleanup (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912251#comment-13912251 ] Leif Hedstrom commented on TS-382: -- +1 socket option cleanup (and bug fixes) --- Key: TS-382 URL: https://issues.apache.org/jira/browse/TS-382 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Leif Hedstrom Assignee: Alan M. Carroll Fix For: 6.0.0 This is a bug moved from Y! Bugzilla, I'm posting the original bug description and a few comments separately. Note that the bug description is fairly limited, but while looking at this code, I noticed a lot of oddities with the socket option support (lots of hardcoded stuff, and most of it is not configurable). Note that the original bug should have been fixed already in Apache TS, but the other comments are still applicable. From Bugzilla (posted by Leif): We have two socket option config options in records.config: proxy.config.net.sock_option_flag_in proxy.config.net.sock_option_flag_out With accept thread enabled, at least the _in option isn't honored. There are possibly other cases in UnixNetAccept.cc that we don't honor these flags either. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2405) Change the default for proxy.config.net.sock_option_flag_out to 1
[ https://issues.apache.org/jira/browse/TS-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2405. --- Resolution: Fixed I've committed this, thanks for the patches / suggestion. Lets hope this is good? :) Change the default for proxy.config.net.sock_option_flag_out to 1 - Key: TS-2405 URL: https://issues.apache.org/jira/browse/TS-2405 Project: Traffic Server Issue Type: Bug Components: Configuration, HTTP Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: 5.0.0 TCP_NODELAY should be set on the outgoing socket. We see delays on POST requests. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2417) forward secrecy for non-EC key types
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2417: -- Assignee: James Peach forward secrecy for non-EC key types Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, Security, SSL Reporter: Bryan Call Assignee: James Peach Fix For: 5.0.0 mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[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: -- Labels: api-change (was: ) 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 Labels: api-change Fix For: 5.0.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.5#6160)
[jira] [Commented] (TS-2417) forward secrecy for non-EC key types
[ https://issues.apache.org/jira/browse/TS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912297#comment-13912297 ] Leif Hedstrom commented on TS-2417: --- James, assigning this to you, you're our only hope. forward secrecy for non-EC key types Key: TS-2417 URL: https://issues.apache.org/jira/browse/TS-2417 Project: Traffic Server Issue Type: Improvement Components: HTTP, Security, SSL Reporter: Bryan Call Assignee: James Peach Fix For: 5.0.0 mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2407) we should add API TSUrlStringGetBuf in ts.h
[
https://issues.apache.org/jira/browse/TS-2407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2407:
--
Labels: api-addition (was: )
we should add API TSUrlStringGetBuf in ts.h
---
Key: TS-2407
URL: https://issues.apache.org/jira/browse/TS-2407
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Yu Qing
Assignee: James Peach
Labels: api-addition
Fix For: 5.0.0
Attachments: 0001-TS-2407-add-API-TSUrlStringGetBuf.patch
the existing API TSUrlStringGet call ats_malloc to malloc buffer for the url
string. the caller should call ats_free to free the buffer. the API prototype
is:
tsapi char* TSUrlStringGet(TSMBuffer bufp, TSMLoc offset, int* length);
call this API is expensive because dynamic memory alloc and free.
we wish the buffer can be passed in. the new API prototype is:
tsapi char* TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc offset, char *buff, int
buf_size, int* length);
the implements as:
char *
TSUrlStringGetBuf(TSMBuffer bufp, TSMLoc obj, char *buff, int buf_size, int*
length)
{
sdk_assert(sdk_sanity_check_mbuffer(bufp) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_url_handle(obj) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)buff) == TS_SUCCESS);
sdk_assert(sdk_sanity_check_null_ptr((void*)length) == TS_SUCCESS);
URLImpl *url_impl = (URLImpl *) obj;
return url_string_get_buf(url_impl, buff, buf_size, length);
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2423) Add option for server sessions that use auth headers that can be placed into the shared pool
[
https://issues.apache.org/jira/browse/TS-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912301#comment-13912301
]
Leif Hedstrom commented on TS-2423:
---
Maybe add more switches to the existing settings? Maybe it's just me, but
prefer fewer configurations, and more options for those configs... Granted,
values like 1, 2, and 3 are pretty non-descriptive, but we could fix that later
as part of e.g. a Lua config format (where the values can be Lua constants).
Add option for server sessions that use auth headers that can be placed into
the shared pool
Key: TS-2423
URL: https://issues.apache.org/jira/browse/TS-2423
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Bryan Call
Assignee: Bryan Call
Fix For: 5.0.0
When a request has an authentication header the server session is marked
private and can't be shared across client sessions.
{code}
// If we are sending authorizations headers, mark the connection private
if (t_state.hdr_info.server_request.presence(MIME_PRESENCE_AUTHORIZATION |
MIME_PRESENCE_PROXY_AUTHORIZATION
|
MIME_PRESENCE_WWW_AUTHENTICATE)) {
server_session-private_session = true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2431:
--
Summary: Add SPDY support to ATS (was: Add SPDY supporting to ATS)
Add SPDY support to ATS
---
Key: TS-2431
URL: https://issues.apache.org/jira/browse/TS-2431
Project: Traffic Server
Issue Type: New Feature
Components: HTTP
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments: 0001-TS-2431-Preparation-of-SPDY-protocol.V3.patch,
0002-TS-2431-Add-autoconf-options-for-SPDY.V3.patch,
0003-TS-2431-Extends-and-optimizes-FetchSM.V3.patch,
0004-TS-2431-Implement-dechunk-supporting-in-FetchSM.V3.patch,
0005-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V3.patch,
0006-TS-2431-Add-SSL-supporting-for-SPDY.V3.patch,
0007-TS-2431-Set-proto_type-properly-for-HttpSM.V3.patch,
0008-TS-2431-Add-client_req_proto_type-cqpt-field-into-lo.V3.patch,
0009-TS-2431-Close-SPDY-request-when-SPDY-is-not-endabled.V3.patch,
0010-TS-2431-Fix-infinite-loop-when-reading-the-fist-byte.V3.patch,
0011-TS-2431-Fix-dechunking-on-FetchSM-s-response-data.V3.patch,
0012-TS-2431-Set-the-water-mark-of-resp_buffer-with-INT64.V3.patch,
0013-TS-2431-Set-eof-flag-to-prevent-spdy-client-hang.V3.patch,
0014-TS-2431-Ignore-fetch-errors-after-FETCH_BODY_DONE.V3.patch,
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
I must say, sorry for my late. And now, I have finished the first version,
the migration of Taobao SPDY plugin to ATS core.
But seriously speaking, the migration to ATS core is finished *partially*. I
had tried to remove the dependency of *fetcher* library created by @Quehan
and create a specific VC for each http request in spdy sm, but I found it was
too difficult, so I give up temporarily.
Let me push this series patches to here before it's perfect enough, at least,
this series can statisfy TAOBAO's current demand (in fact, this version has
had good performance in our testing, but it can do much better I think).
I had thought another solution instread of recreating a new VC for each http
request in spdy sm, which will replace FetchSM's function and speed up SPDY
protocol, but will not change the framework of this version. So I can hacking
it based on these patches in the future.
== *UPDATE* ==
- From now on, SPDY can work with SSL, Cheers!
==How to test it==
- Install *spdylay* library, here is URL of this lib:
Download spdylay library: https://github.com/tatsuhiro-t/spdylay
- Use '--enable-spdy' option to compile ATS:
{code}
$ ./configure --enable-spdy
$ make all make install
{code}
- SPDY can work with SSL now, it depends on OpenSSL = 1.0.1. You can use
'--with-openssl=dir' option to tell ATS where to search it:
{code}
$ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
{code}
- Need not to config anything if you just want to test SPDY without SSL.
The code can recognize SPDY or HTTP by reading this first byte of request.
- When test SPDY+SSL, you may need to configure SSL key properly for ATS.
- You can use *spdycat* in spdylay(or other SPDY client) to do request, for
example:
{code}
# SPDY without SSL
$ spdycat -3 -v --no-tls http://localhost/b.txt
# SPDY + SSL
$ spdycat -3 -v https://localhost/b.txt
{code}
- You can enable debuging logs of SPDY:
{code}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING spdy
{code}
==TODO===
- Migrate spdy configuration to ATS records.config
Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2462) FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation which is deleted`
[
https://issues.apache.org/jira/browse/TS-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2462:
--
Labels: crash (was: )
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
Key: TS-2462
URL: https://issues.apache.org/jira/browse/TS-2462
Project: Traffic Server
Issue Type: Bug
Components: HTTP, TS API
Reporter: bettydramit
Labels: crash
Fix For: 5.0.0
4.0.1 -4.1.2
{code}
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.4(+0x141e8)[0x2b716e8ac1e8]
/usr/lib64/trafficserver/libtsutil.so.4(+0x128df)[0x2b716e8aa8df]
/usr/bin/traffic_server[0x4af6b4]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4d08b5]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4d120a]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x2c3)[0x4d2123]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a37ff]
/usr/bin/traffic_server(EThread::execute()+0x6e3)[0x6a4423]
/usr/bin/traffic_server[0x6a269a]
/lib64/libpthread.so.0(+0x7851)[0x2b7170708851]
/lib64/libc.so.6(clone+0x6d)[0x2b71713ac90d]
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2462) FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation which is deleted`
[
https://issues.apache.org/jira/browse/TS-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912304#comment-13912304
]
Leif Hedstrom commented on TS-2462:
---
[~bettydreamit] Any ideas how to reproduce this ?
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
Key: TS-2462
URL: https://issues.apache.org/jira/browse/TS-2462
Project: Traffic Server
Issue Type: Bug
Components: HTTP, TS API
Reporter: bettydramit
Labels: crash
Fix For: 5.0.0
4.0.1 -4.1.2
{code}
FATAL: InkAPI.cc:983: failed assert `!Plugin tries to use a continuation
which is deleted`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.4(+0x141e8)[0x2b716e8ac1e8]
/usr/lib64/trafficserver/libtsutil.so.4(+0x128df)[0x2b716e8aa8df]
/usr/bin/traffic_server[0x4af6b4]
/usr/bin/traffic_server(PluginVC::process_read_side(bool)+0x375)[0x4d08b5]
/usr/bin/traffic_server(PluginVC::process_write_side(bool)+0x57a)[0x4d120a]
/usr/bin/traffic_server(PluginVC::main_handler(int, void*)+0x2c3)[0x4d2123]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a37ff]
/usr/bin/traffic_server(EThread::execute()+0x6e3)[0x6a4423]
/usr/bin/traffic_server[0x6a269a]
/lib64/libpthread.so.0(+0x7851)[0x2b7170708851]
/lib64/libc.so.6(clone+0x6d)[0x2b71713ac90d]
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2527) mgmtapi.h should be C style
[
https://issues.apache.org/jira/browse/TS-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2527:
--
Labels: api-change (was: )
mgmtapi.h should be C style
---
Key: TS-2527
URL: https://issues.apache.org/jira/browse/TS-2527
Project: Traffic Server
Issue Type: Bug
Components: Management API
Reporter: Zhao Yongming
Labels: api-change
Fix For: 5.0.0
{code}
/*--- statistics operations ---*/
/* TSStatsReset: sets all the statistics variables to their default values
* Input: cluster - Reset the stats clusterwide or not
* Outpue: TSErrr
*/
tsapi TSError TSStatsReset(bool cluster, const char *name = NULL);
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (TS-2478) Fix multiple format string errors in C++ API
[ https://issues.apache.org/jira/browse/TS-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912306#comment-13912306 ] Leif Hedstrom commented on TS-2478: --- I think this actually landed as part of another question. [~hsn] Can you verify if current master still has these problems? Fix multiple format string errors in C++ API Key: TS-2478 URL: https://issues.apache.org/jira/browse/TS-2478 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: Radim Kolar Assignee: Brian Geffon Fix For: 5.0.0 Attachments: patch-async-httpfetch, patch-gzip-deflate-log, patch-gzip-inflate, patch-transformationplugin-format Cleaned rest of errors found by clang static analyzer 3.3 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2493) API: introducing UDP API
[ https://issues.apache.org/jira/browse/TS-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2493: -- Labels: api-addition (was: UDP) API: introducing UDP API Key: TS-2493 URL: https://issues.apache.org/jira/browse/TS-2493 Project: Traffic Server Issue Type: Improvement Components: TS API Affects Versions: 4.1.2 Reporter: Zhao Yongming Assignee: weijin Labels: api-addition Fix For: 5.0.0 Attachments: api.patch when doing UDP tasks in plugins, there is no UDP api available to use, we need to introduce those APIs task for [~xinyuziran] -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2485) move C++ API to an api/ directory
[
https://issues.apache.org/jira/browse/TS-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2485:
--
Labels: api-change (was: )
move C++ API to an api/ directory
-
Key: TS-2485
URL: https://issues.apache.org/jira/browse/TS-2485
Project: Traffic Server
Issue Type: Improvement
Components: Core, TS API
Reporter: James Peach
Assignee: Brian Geffon
Labels: api-change
Fix For: 5.0.0
The C++ API is currently in {{lib/atscppapi/}}. The {{lib/}} directory is
used for internal project library code, so it's a weird place to put API
libraries. The C API is in {{proxy/api}}, so that could make sense. It might
also make sense for there to be a top-level {{api/}} directory for both
public APIs.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2528) better bool handling in mgmtapi.h
[
https://issues.apache.org/jira/browse/TS-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2528:
--
Labels: api-change (was: )
better bool handling in mgmtapi.h
-
Key: TS-2528
URL: https://issues.apache.org/jira/browse/TS-2528
Project: Traffic Server
Issue Type: Bug
Components: Management API
Reporter: Zhao Yongming
Labels: api-change
Fix For: 5.0.0
{code}
tsapi bool TSListIsEmpty(TSList l);
tsapi bool TSListIsValid(TSList l);
tsapi bool TSIpAddrListIsEmpty(TSIpAddrList ip_addrl);
tsapi bool TSIpAddrListIsValid(TSIpAddrList ip_addrl);
tsapi bool TSPortListIsEmpty(TSPortList portl);
tsapi bool TSPortListIsValid(TSPortList portl);
tsapi bool TSStringListIsEmpty(TSStringList strl);
tsapi bool TSStringListIsValid(TSStringList strl);
tsapi bool TSIntListIsEmpty(TSIntList intl);
tsapi bool TSIntListIsValid(TSIntList intl, int min, int max);
tsapi bool TSDomainListIsEmpty(TSDomainList domainl);
tsapi bool TSDomainListIsValid(TSDomainList domainl);
tsapi TSError TSRestart(bool cluster);
tsapi TSError TSBounce(bool cluster);
tsapi TSError TSStatsReset(bool cluster, const char *name = NULL);
tsapi TSError TSEventIsActive(char *event_name, bool * is_current);
{code}
and we have:
{code}
#if !defined(linux)
#if defined (__SUNPRO_CC) || (defined (__GNUC__) || ! defined(__cplusplus))
#if !defined (bool)
#if !defined(darwin) !defined(freebsd) !defined(solaris)
// XXX: What other platforms are there?
#define bool int
#endif
#endif
#if !defined (true)
#define true 1
#endif
#if !defined (false)
#define false 0
#endif
#endif
#endif // not linux
{code}
I'd like we can make it a typedef or replace bool with int completely, to
make things better to be parsed by SWIG tools etc.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (TS-2535) Reorganize the Perl modules, and move autoconf stuff to Apache::TS
[ https://issues.apache.org/jira/browse/TS-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2535: -- Labels: api-change (was: ) Reorganize the Perl modules, and move autoconf stuff to Apache::TS -- Key: TS-2535 URL: https://issues.apache.org/jira/browse/TS-2535 Project: Traffic Server Issue Type: Improvement Components: Management API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Labels: api-change Fix For: 5.0.0 Instead of autoconf'ig AdminClient.pm, I'd like to move all that logic over to Apache::TS. This allows for one module to be shared across all other .pm's, where they call can get to this autoconf configuration stuff. There's also a build problem with the current AdminClient.pm.in build, so we should fix this here too. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2542) Turn on caching zero length responses by default
[ https://issues.apache.org/jira/browse/TS-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912313#comment-13912313 ] ASF subversion and git services commented on TS-2542: - Commit 4e4518cd5de02adf9a83c611745357c1966c78ef in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4e4518c ] TS-2542 Turn on caching zero length responses by default Turn on caching zero length responses by default Key: TS-2542 URL: https://issues.apache.org/jira/browse/TS-2542 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: 5.0.0 301 response is not being cached in forward proxy mode if content length is zero bytes. Test with a zero byte content length - doing multiple requests: [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s http://homer.bryancall.com/301.php HTTP/1.1 301 Moved Permanently Date: Wed, 29 Jan 2014 23:44:03 GMT Server: ATS X-Powered-By: PHP/5.5.7 Location: http://www.yahoo.com/ Content-Length: 0 Content-Type: text/html; charset=UTF-8 Age: 0 Proxy-Connection: keep-alive Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t cCMi p sS]) Is cached if the content length is non-zero: [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s http://homer.bryancall.com/301.php HTTP/1.1 301 Moved Permanently Date: Wed, 29 Jan 2014 23:48:11 GMT Server: ATS X-Powered-By: PHP/5.5.7 Location: http://www.yahoo.com/ Content-Length: 4 Content-Type: text/html; charset=UTF-8 Age: 7 Proxy-Connection: keep-alive Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TS-2542) Turn on caching zero length responses by default
[ https://issues.apache.org/jira/browse/TS-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2542. --- Resolution: Fixed Turn on caching zero length responses by default Key: TS-2542 URL: https://issues.apache.org/jira/browse/TS-2542 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Bryan Call Assignee: Leif Hedstrom Fix For: 5.0.0 301 response is not being cached in forward proxy mode if content length is zero bytes. Test with a zero byte content length - doing multiple requests: [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s http://homer.bryancall.com/301.php HTTP/1.1 301 Moved Permanently Date: Wed, 29 Jan 2014 23:44:03 GMT Server: ATS X-Powered-By: PHP/5.5.7 Location: http://www.yahoo.com/ Content-Length: 0 Content-Type: text/html; charset=UTF-8 Age: 0 Proxy-Connection: keep-alive Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScMsSfWpSeN:t cCMi p sS]) Is cached if the content length is non-zero: [bcall@mac-bryan-wire ~]$ curl -x homer:8080 -D - -o /dev/null -s http://homer.bryancall.com/301.php HTTP/1.1 301 Moved Permanently Date: Wed, 29 Jan 2014 23:48:11 GMT Server: ATS X-Powered-By: PHP/5.5.7 Location: http://www.yahoo.com/ Content-Length: 4 Content-Type: text/html; charset=UTF-8 Age: 7 Proxy-Connection: keep-alive Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/4.2.0 [uScHs f p eN:t cCHi p s ]) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2561) remove app-template from examples
[ https://issues.apache.org/jira/browse/TS-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912315#comment-13912315 ] Leif Hedstrom commented on TS-2561: --- [~zym] Update on this ? remove app-template from examples - Key: TS-2561 URL: https://issues.apache.org/jira/browse/TS-2561 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 5.0.0 Reporter: Zhao Yongming Assignee: Zhao Yongming Fix For: 5.0.0 due to the STANDALONE IOCORE is removed, the app-template example should not be there. and most of the app-template STANDALONE IOCORE design purpose is able to satisfied with the protocol plugin. let us remove it. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TS-2268) Add support for opening protocol traffic sockets through the traffic_manager
[ https://issues.apache.org/jira/browse/TS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2268: -- Labels: api-addition (was: api-change) Add support for opening protocol traffic sockets through the traffic_manager Key: TS-2268 URL: https://issues.apache.org/jira/browse/TS-2268 Project: Traffic Server Issue Type: Improvement Components: Plugins, TS API Reporter: Uri Shachar Assignee: Uri Shachar Labels: api-addition Fix For: 5.0.0 Add a TSNetAcceptNamedDescriptor(contp, char *) function to allow a protocol plugin to set a callback for accepting new connections on a socket opened by the traffic_manager (that's defined like 2345:plugin:name=myname in the server_ports configuration). This has three advantages on opening a socket using TSNetAccept: 1) If the traffic_server crashes and restarts, new connections won't be rejected while we recover - This is the main selling point of the new API. 2) Support for all port configuration flags (Which also exists when using TSPortDescriptorAccept) 3) Allow for a single point of configuration for all ATS ports -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (TS-2576) Add Oct/Hex escape representation into LogFormat
[
https://issues.apache.org/jira/browse/TS-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13912316#comment-13912316
]
Leif Hedstrom commented on TS-2576:
---
Lets get this landed.
Add Oct/Hex escape representation into LogFormat
Key: TS-2576
URL: https://issues.apache.org/jira/browse/TS-2576
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0001-TS-2576-Add-Oct-Hex-escape-representation-into-LogFo.V2.patch,
0001-TS-2576-Add-Oct-Hex-escape-representation-into-LogFo.patch
By default, we use white space ' ' as delimiter in LogFormat:
{code}
LogFormat
Name = Cdn_access_log/
Format = %cqhm %cquuc %pscl %psql %crc %fsi/
/LogFormat
{code}
Of course, we could use other characters, such as comma(',') or any other
visible character or string.
But we found that, the value of fields may contain the same delimiter
characters, it would case hard to extract from log file.
So I develop a patch, it will introduce Oct/Hex escape sequences
representation in LogFormat, for example:
{code}
LogFormat
Name = Cdn_access_log/
Format =
%cqhm\001\002%cquuc\001\002%pscl\001\002%psql\001\002%crc\001\002%fsi/
/LogFormat
{code}
In the above example, '\001\002' are two characters: '\001', '\002' in Oct
escape sequence representation.
This patch now supports two forms(the same with the format in C lauguage):
* Oct escape sequence:
{code}
'\abc': a,b,c should be one of [0-9], and (a*8^2 + b*8 + c) should be greater
than 0 and less then 255.
{code}
* Hex escape sequence:
{code}
'\xab': a,b should one [0-9, a-f, A-F], and (a*16 + b) should be greater than
0 and less then 255.
{code}
{code}
We can also use '\\' to output '\' character itself.
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[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-tabpanelfocusedCommentId=13912340#comment-13912340 ] ASF subversion and git services commented on TS-2210: - Commit 81c3eaf725118b108b44c0a6ebf86a939f0df5b3 in trafficserver's branch refs/heads/master from [~Kang Li] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=81c3eaf ] TS-2210: add a plugin API to manipulate the session's SSL context 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 Assignee: James Peach Labels: Review, api-change Fix For: 5.0.0 Attachments: 2210.diff, TS-2210-2.diff 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.5#6160)
[jira] [Updated] (TS-1584) Exposing client SSL certificate verification result in plugin API
[ https://issues.apache.org/jira/browse/TS-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1584: Fix Version/s: (was: 6.0.0) 5.0.0 Exposing client SSL certificate verification result in plugin API -- Key: TS-1584 URL: https://issues.apache.org/jira/browse/TS-1584 Project: Traffic Server Issue Type: Improvement Components: SSL, TS API Affects Versions: 3.3.4 Reporter: Thach Tran Assignee: James Peach Priority: Minor Labels: patch Fix For: 5.0.0 Attachments: 0001-Exposing-client-ssl-certificate-verification-result-.patch, 0001-TS-1584-Retaining-some-info-from-client-certificate-.patch I'm writing an authentication plugin for traffic server and would like to implement the following logic: * If the client supplies valid certificate over ssl, allow the transaction to proceed with no further authentication. * Otherwise challenge the client with username/password authentication. Currently if I turn on client certificate checking in TS (proxy.config.ssl.client.certification_level 0), the result of the client certificate verification happens at the SSLNetVConnection level and plugin hooks have no knowledge of this. This makes implementing the aforementioned logic not possible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
