[jira] [Commented] (TS-1885) autoconf_port doesn't obey incoming_ip_to_bind
[
https://issues.apache.org/jira/browse/TS-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726233#comment-13726233
]
Leif Hedstrom commented on TS-1885:
---
There is a configuration for this, e.g.
{code}
CONFIG proxy.config.admin.autoconf.localhost_only INT 1
{code}
Does that suffice ? We'd still bind the 0.0.0.0 address, but only allow conns
from localhost. Should we make this option 1 by default? Speak up now, so we
can make this change asap if appropriate.
autoconf_port doesn't obey incoming_ip_to_bind
--
Key: TS-1885
URL: https://issues.apache.org/jira/browse/TS-1885
Project: Traffic Server
Issue Type: Bug
Reporter: Ebrahim Mohammadi
Fix For: 3.5.0
proxy.config.admin.autoconf_port doesn't obey proxy.local.incoming_ip_to_bind
and continues to bind on 0.0.0.0 even though incoming_ip_to_bind is 127.0.0.1.
Seen on 3.2.4 trafficserver package of Debian sid installed on a Debian
wheezy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2086) Remove a few completely unused RecordsConfig.cc settings
[
https://issues.apache.org/jira/browse/TS-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2086:
--
Fix Version/s: 3.3.5
Remove a few completely unused RecordsConfig.cc settings
Key: TS-2086
URL: https://issues.apache.org/jira/browse/TS-2086
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Leif Hedstrom
Fix For: 3.3.5
Found a few more:
{code}
proxy.config.temp_dir
proxy.config.cli_binary
proxy.config.cop_name
proxy.config.manager_name
proxy.config.process_state_dump_mode
proxy.config.server_name
proxy.config.start_script
proxy.config.watch_script
{code}
They are truly no-ops (have no purpose). There were a few more (such as
Product name and Vendor), which I left cause they might have some use as
part of a monitoring system.
Please speak up now if you feel any of these do deserve to linger, even
unused. The reason to remove them is to avoid confusing, such as thinking
changing them would have some sort of effect (which neither does).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2086) Remove a few completely unused RecordsConfig.cc settings
[
https://issues.apache.org/jira/browse/TS-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2086:
-
Assignee: Leif Hedstrom
Remove a few completely unused RecordsConfig.cc settings
Key: TS-2086
URL: https://issues.apache.org/jira/browse/TS-2086
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.5
Found a few more:
{code}
proxy.config.temp_dir
proxy.config.cli_binary
proxy.config.cop_name
proxy.config.manager_name
proxy.config.process_state_dump_mode
proxy.config.server_name
proxy.config.start_script
proxy.config.watch_script
{code}
They are truly no-ops (have no purpose). There were a few more (such as
Product name and Vendor), which I left cause they might have some use as
part of a monitoring system.
Please speak up now if you feel any of these do deserve to linger, even
unused. The reason to remove them is to avoid confusing, such as thinking
changing them would have some sort of effect (which neither does).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2086) Remove a few completely unused RecordsConfig.cc settings
[
https://issues.apache.org/jira/browse/TS-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2086:
--
Description:
Found a few more:
{code}
proxy.config.temp_dir
proxy.config.cli_binary
proxy.config.cop_name
proxy.config.manager_name
proxy.config.process_state_dump_mode
proxy.config.server_name
proxy.config.start_script
proxy.config.watch_script
proxy.config.history_info_enabled
{code}
They are truly no-ops (have no purpose). There were a few more (such as
Product name and Vendor), which I left cause they might have some use as
part of a monitoring system.
Please speak up now if you feel any of these do deserve to linger, even unused.
The reason to remove them is to avoid confusing, such as thinking changing them
would have some sort of effect (which neither does).
was:
Found a few more:
{code}
proxy.config.temp_dir
proxy.config.cli_binary
proxy.config.cop_name
proxy.config.manager_name
proxy.config.process_state_dump_mode
proxy.config.server_name
proxy.config.start_script
proxy.config.watch_script
{code}
They are truly no-ops (have no purpose). There were a few more (such as
Product name and Vendor), which I left cause they might have some use as
part of a monitoring system.
Please speak up now if you feel any of these do deserve to linger, even unused.
The reason to remove them is to avoid confusing, such as thinking changing them
would have some sort of effect (which neither does).
Remove a few completely unused RecordsConfig.cc settings
Key: TS-2086
URL: https://issues.apache.org/jira/browse/TS-2086
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.5
Found a few more:
{code}
proxy.config.temp_dir
proxy.config.cli_binary
proxy.config.cop_name
proxy.config.manager_name
proxy.config.process_state_dump_mode
proxy.config.server_name
proxy.config.start_script
proxy.config.watch_script
proxy.config.history_info_enabled
{code}
They are truly no-ops (have no purpose). There were a few more (such as
Product name and Vendor), which I left cause they might have some use as
part of a monitoring system.
Please speak up now if you feel any of these do deserve to linger, even
unused. The reason to remove them is to avoid confusing, such as thinking
changing them would have some sort of effect (which neither does).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2055) make port 8083 interface configurable - for src port TP purposes
[ https://issues.apache.org/jira/browse/TS-2055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2055: -- Fix Version/s: (was: 3.5.1) (was: 3.4.1) 3.5.0 make port 8083 interface configurable - for src port TP purposes - Key: TS-2055 URL: https://issues.apache.org/jira/browse/TS-2055 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: Aidan McGurn Assignee: Alan M. Carroll Fix For: 3.5.0 the mgmt port 8083 is currently wildcard (INADDR_ANY) with no means to change this. We have changed this for now to be INADDR_LOOPBACK and as directed by Alan are opening a TS Jira to get this a configurable item (or at least one of these options he mentioned): (1) set this to LOOPBACK if autoconf.localport_only is set or (2) add a configuration value to explicit set the binding IP address. The driver for this is we require a src port TP system. Testing shows that this is one of the ports causing a 502 bind issue (on the OS backend connection) as its already in use. Binding to explicit interface should solve this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1885) autoconf_port doesn't obey incoming_ip_to_bind
[ https://issues.apache.org/jira/browse/TS-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1885. --- Resolution: Duplicate Fix Version/s: (was: 3.5.0) I believe these are the same issue. autoconf_port doesn't obey incoming_ip_to_bind -- Key: TS-1885 URL: https://issues.apache.org/jira/browse/TS-1885 Project: Traffic Server Issue Type: Bug Reporter: Ebrahim Mohammadi proxy.config.admin.autoconf_port doesn't obey proxy.local.incoming_ip_to_bind and continues to bind on 0.0.0.0 even though incoming_ip_to_bind is 127.0.0.1. Seen on 3.2.4 trafficserver package of Debian sid installed on a Debian wheezy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-306) enable log rotation for diags.log
[ https://issues.apache.org/jira/browse/TS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-306: - Fix Version/s: (was: 3.5.1) sometime enable log rotation for diags.log - Key: TS-306 URL: https://issues.apache.org/jira/browse/TS-306 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Miles Libbey Priority: Critical Fix For: sometime (from yahoo bug 913896) Original description by Leif Hedstrom 3 years ago at 2006-12-04 12:42 There might be reasons why this file might get filled up, e.g. libraries used by plugins producing output on STDOUT/STDERR. A few suggestions have been made, to somehow rotate traffic.out. One possible solution (suggested by Ryan) is to use cronolog (http://cronolog.org/), which seems like a fine idea. Comment 1 by Joseph Rothrock 2 years ago at 2007-10-17 09:13:24 Maybe consider rolling diags.log as well. -Feature enhancement. Comment 2 by Kevin Dalley 13 months ago at 2009-03-04 15:32:18 When traffic.out gets filled up, error.log stops filing up, even though rotation is turned on. This is counter-intuitive. Rotation does not control traffic.out, but a large traffic.out will stop error.log from being written. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-228) Cleanup usage of long in all code
[
https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726316#comment-13726316
]
Leif Hedstrom commented on TS-228:
--
Some candidates:
{code}
build/tcl.m4: tcl_type_64bit=__int64, tcl_type_64bit=long long)
build/tcl.m4: AC_DEFINE(TCL_WIDE_INT_IS_LONG, 1, [Are wide integers to be
implemented with C 'long's?])
cop/TrafficCop.cc:long long memfree, swapfree, swapsize;
doc/admin/index.en.rst:interactions and optimize performance. Along with other
information, the
doc/reference/configuration/records.config.en.rst:This solution must be
considered interim. In the longer term, it
doc/sdk/io-guide/transformations.en.rst: /* Tell the read buffer that we
have read the data and are no longer interested in it. */
example/append-transform/append-transform.c: longer interested in it. */
example/bnull-transform/bnull-transform.c: longer interested in it. */
example/null-transform/null-transform.c: * longer interested in it.
example/remap/remap.cc:static volatile unsigned long processing_counter = 0;
// sequential counter
example/remap/remap.cc: unsigned long _processing_counter =
++processing_counter; // one more function call (in real life use mutex to
protect this counter)
example/server-transform/server-transform.c: longer interested in it. */
example/thread-pool/psi.c:/* Consume data we've processed an we are no
longer interested in */
iocore/cache/Cache.cc:vol_dirlen(this), (long long)this-len,
(double)vol_dirlen(this) / (double)this-len * 100.0);
iocore/cluster/ClusterCache.cc:unmarshal_CacheOpMsg_long(void *data, int
NeedByteSwap)
iocore/cluster/ClusterCache.cc: int flen =
CacheOpMsg_long::sizeof_fixedlen_msg();
iocore/cluster/ClusterCache.cc: int flen =
CacheOpMsg_long::sizeof_fixedlen_msg();
iocore/cluster/ClusterProcessor.cc:unsigned long cluster_sockopt_flags = 0;
iocore/cluster/ClusterProcessor.cc:unsigned long cluster_packet_mark = 0;
iocore/cluster/ClusterProcessor.cc:unsigned long cluster_packet_tos = 0;
iocore/cluster/P_ClusterCacheInternal.h: CacheOpMsg_long(uint16_t vers =
CACHE_OP_LONG_MESSAGE_VERSION):
iocore/cluster/P_ClusterInline.h: int vers =
CacheOpMsg_long::protoToVersion(owner_machine-msg_proto_major);
iocore/cluster/P_ClusterInline.h: int vers =
CacheOpMsg_long::protoToVersion(m-msg_proto_major);
iocore/cluster/P_ClusterMachine.h:#define NO_RACE_DELAY
HRTIME_HOUR // a long long time
iocore/eventsystem/I_SocketManager.h: int poll(struct pollfd *fds, unsigned
long nfds, int timeout);
iocore/eventsystem/Lock.cc:fprintf(stderr, WARNING: holding lock %s:%d too
long for %s\n,
iocore/eventsystem/P_UnixSocketManager.h:SocketManager::poll(struct pollfd
*fds, unsigned long nfds, int timeout)
iocore/hostdb/include/Machine.h:#define NO_RACE_DELAY
HRTIME_HOUR // a long long time
iocore/net/I_NetVConnection.h: void set_sock_param(int _recv_bufsize, int
_send_bufsize, unsigned long _opt_flags,
iocore/net/I_NetVConnection.h: unsigned long _packet_mark
= 0, unsigned long _packet_tos = 0);
iocore/net/P_UnixNetVConnection.h:NetVCOptions::set_sock_param(int
_recv_bufsize, int _send_bufsize, unsigned long _opt_flags,
iocore/net/P_UnixNetVConnection.h: unsigned long
_packet_mark, unsigned long _packet_tos)
iocore/net/SSLUtils.cc:static unsigned long
iocore/net/SSLUtils.cc: return (unsigned long) (eth-id);
iocore/net/SSLUtils.cc: unsigned long l;
iocore/net/SSLUtils.cc: unsigned long es;
iocore/net/test_certlookup.cc: box.check(lookup.findInfoInHash(endpoint.ip6)
== context.ip6, IPv6 longest match lookup);
iocore/net/test_certlookup.cc: box.check(lookup.findInfoInHash(endpoint.ip6p)
== context.ip6p, IPv6 longest match lookup w/ port);
iocore/net/test_certlookup.cc: box.check(lookup.findInfoInHash(endpoint.ip4)
== context.ip4, IPv4 longest match lookup);
iocore/net/test_certlookup.cc: box.check(lookup.findInfoInHash(endpoint.ip4p)
== context.ip4p, IPv4 longest match lookup w/ port);
lib/ts/IpMap.h: This holds an interval based on a metric @a T along with
lib/ts/IpMapConf.cc:snprintf(err, ERR_STRING_LEN, IP address too long);
lib/ts/ink_align.h:// messages concerning coercion between void* and unsigned
long.
lib/ts/ink_atomic.h:typedef unsigned long uint64_s;
lib/ts/ink_atomic.h:static inline int ink_atomic_increment(pvint32 mem,
long value) { return ((uint32_t)atomic_add_32_nv((pvuint32)mem,
(uint32_t)value)) - value; }
lib/ts/ink_cap.cc:(unsigned long long)pthread_self() );
lib/ts/ink_hrtime.cc:squid_timestamp_to_buf(char *buf, unsigned int buf_size,
long timestamp_sec, long timestamp_usec)
lib/ts/ink_hrtime.h:int squid_timestamp_to_buf(char *buf, unsigned int
buf_size, long timestamp_sec, long timestamp_usec);
lib/ts/ink_memory.cc: // this was long long ago
[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: - Fix Version/s: (was: sometime) 3.5.0 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 Fix For: 3.5.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-745: - Fix Version/s: (was: 3.5.0) 3.3.5 Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: weijin Fix For: 3.3.5 Attachments: 0001-TS-745-support-interim-caching-in-storage.patch, 0001-TS-745-support-interim-caching-in-storage_rebased.patch, ts-745.diff, TS-ssd-2.patch, TS-ssd.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2087) Reimplement / refactor / fix the SSD code
Leif Hedstrom created TS-2087: - Summary: Reimplement / refactor / fix the SSD code Key: TS-2087 URL: https://issues.apache.org/jira/browse/TS-2087 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom This is in relation to TS-745, see that for some of the comments that's been added re: the code that was landed. I really feel we ought to clean up a lot of this, and address all the concerns that was brought up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2087) Reimplement / refactor / fix the SSD code
[ https://issues.apache.org/jira/browse/TS-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2087: -- Fix Version/s: 3.5.0 Reimplement / refactor / fix the SSD code - Key: TS-2087 URL: https://issues.apache.org/jira/browse/TS-2087 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Leif Hedstrom Fix For: 3.5.0 This is in relation to TS-745, see that for some of the comments that's been added re: the code that was landed. I really feel we ought to clean up a lot of this, and address all the concerns that was brought up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-794) ssl session reuse can not pass sslswamp testing
[
https://issues.apache.org/jira/browse/TS-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726333#comment-13726333
]
Leif Hedstrom commented on TS-794:
--
What's the status on this? Should we close it ?
ssl session reuse can not pass sslswamp testing
---
Key: TS-794
URL: https://issues.apache.org/jira/browse/TS-794
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 2.1.8
Environment: sslv3 tlsv1
Reporter: Zhao Yongming
Labels: A
Fix For: 3.5.0
When I testing from the patches from qianshi, for TS-718, the ssl session
resumption looks perfect, but still can not pass the sslswamp testing, it
looks like the second and later request will not be handled from the https
connection. it may be a issue for https handler, here is some information
testing from sslswamp:
{code}
[root@unknown-10-62-163-x ~]# sslswamp -connect IP:10.32.21.75:443 -num 1
-count 4 -session srrr -update 10 -request GET
https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg
HTTP/1.0\r\n\r\n -session_ids -nologo -expect 64000 -sslmeth tlsv1
No 'cacert' supplied, trying defaults ... '/usr/share/swamp/CA.pem' found.
no client cert provided, continuing anyway.
Certificate verification failed, probably a self-signed server cert *or*
the signing CA cert is not trusted by us (hint: use '-CAfile').
This message will only be printed once
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 0 failed, resumes(+1,-0) 0.01
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
120 seconds since starting, 1 successful, 1 failed, resumes(+1,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
120 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 1 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
240 seconds since starting, 1 successful, 2 failed, resumes(+2,-0) 0.00
ops/sec
session-id[conn:0]:04E7E83CD58E8D566673EDB244146C808ECF7AF517CF39282017E053C7A7D0CC
240 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 2 failed, resumes(+3,-0) 0.00
ops/sec
361 seconds since starting, 1 successful, 3 failed, resumes(+3,-0) 0.00
ops/sec
{code}
the log from traffic.out:
{code}
[May 20 18:30:59.544] Manager {140339380279072} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '10'
[May 20 18:30:59.544] Manager {140339380279072} NOTE: [Alarms::signalAlarm]
Server Process born
[May 20 18:31:00.564] {47816222021376} STATUS: opened
/var/log/trafficserver/diags.log
[May 20 18:31:00.613] {47816222021376} NOTE: updated diags config
[May 20 18:31:00.648] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:00.784] Server {47816222021376} NOTE: cache clustering disabled
[May 20 18:31:01.237] Server {47816222021376} DEBUG: (ssl)
[SSLNetProcessor::initSSLServerCTX] set the callback for external session
caching.
[May 20 18:31:01.412] Server {47816222021376} NOTE: logging initialized[7],
logging_mode = 3
[May 20 18:31:01.669] Server {47816222021376} NOTE: traffic server running
[May 20 18:31:01.793] Server {47816237516544} NOTE: cache enabled
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
[ssl_callback_NewSessionCacheEntry] store id
[D91C5F59EB43C5E8864303B449B9B1673D3218300EE03FDC4790125A7BCB521D]'s session
into cache.
[May 20 18:31:57.001] Server {47816310503168} DEBUG: (ssl)
SSLNetVConnection::sslServerHandShakeEvent, handshake completed successfully
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4096
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=82
SSL Read
GET https://img02.taobaocdn.com/tps/i2/T1.SVEXcXJ-770-300.jpg HTTP/1.0
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] rres=-1
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_WOULD_BLOCK
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] bytes_read=82
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[SSL_NetVConnection::ssl_read_from_net] b-write_avail()=4014
[May 20 18:31:57.004] Server {47816310503168} DEBUG: (ssl)
[jira] [Assigned] (TS-799) Have AdminClient.pm created from .in file
[ https://issues.apache.org/jira/browse/TS-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-799: Assignee: Leif Hedstrom Have AdminClient.pm created from .in file - Key: TS-799 URL: https://issues.apache.org/jira/browse/TS-799 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.0 Reporter: Igor Galić Assignee: Leif Hedstrom Priority: Trivial Fix For: 3.5.0 AdminClient.pm should be created from an .in file. @sockets_def = should be extended with @localstatedir@ on top. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-799) Have AdminClient.pm created from .in file
[ https://issues.apache.org/jira/browse/TS-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-799: - Fix Version/s: (was: sometime) 3.5.0 Have AdminClient.pm created from .in file - Key: TS-799 URL: https://issues.apache.org/jira/browse/TS-799 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.0 Reporter: Igor Galić Priority: Trivial Fix For: 3.5.0 AdminClient.pm should be created from an .in file. @sockets_def = should be extended with @localstatedir@ on top. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-858) traffic_server segmentation_fault when cache storage value is below 65M
[
https://issues.apache.org/jira/browse/TS-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-858:
Assignee: Leif Hedstrom
traffic_server segmentation_fault when cache storage value is below 65M
---
Key: TS-858
URL: https://issues.apache.org/jira/browse/TS-858
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.0.0
Environment: Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 3.5.1
specify the storage as var/trafficserver 64M in the storage.conf,
traffic_server will core dump upon launch, the following is the stack trace:
{noformat}
FATAL: Cache.cc:2293: failed assert `dpb dpb-len == (uint64_t)b`
traffic_server - STACK TRACE:
traffic_server(ink_fatal_va+0x8e)[0x82ef221]
traffic_server(ink_fatal+0x1e)[0x82ef252]
traffic_server(_ink_assert+0x90)[0x82eeb6c]
traffic_server(cplist_reconfigure()+0x2fd)[0x8283054]
traffic_server(CacheProcessor::diskInitialized()+0x19b)[0x827b7d1]
traffic_server(CacheDisk::openDone(int, void*)+0x40)[0x8291142]
traffic_server(CacheDisk::clearDone(int, void*)+0xcc)[0x8290eb2]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x2c)[0x82862c8]
traffic_server(Continuation::handleEvent(int, void*)+0x47)[0x810d871]
traffic_server(EThread::process_event(Event*, int)+0x10e)[0x82e83f2]
traffic_server(EThread::execute()+0xa6)[0x82e862a]
traffic_server[0x82e74b1]
/lib/libpthread.so.0[0x658e99]
/lib/libc.so.6(clone+0x5e)[0x59ed2e]
{noformat}
It will core dump everytime, if the cache size is set to 65M, traffic_server
will launch fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-947:
-
Fix Version/s: (was: sometime)
3.5.0
AIO Race condition on non NT systems
Key: TS-947
URL: https://issues.apache.org/jira/browse/TS-947
Project: Traffic Server
Issue Type: Bug
Components: Core
Environment: stock build with static libts, running on a 4 core server
Reporter: B Wyatt
Assignee: John Plevyak
Fix For: 3.5.0
Attachments: lock-safe-AIO.patch, timed-wait-AIO.patch
Refer to code below. The timeslice starting when a consumer thread
determines that the temp_list is empty (A) and ending when it releases the
aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
and as a result request producers enqueue items on the temporary atomic list
(D). As a consumer in this state will wait for a signal on aio_cond to
proceed before processing the temp_list again, any requests on the temp_list
are effectively stalled until a future request produces this signal or
manually processes the temp_list.
In the case of cache volume initialization, there is no future request and
the initialization sequence soft locks.
{code:title=iocore/aio/AIO.cc(annotated)}
void *
aio_thread_main(void *arg)
{
...
ink_mutex_acquire(my_aio_req-aio_mutex);
for (;;) {
do {
current_req = my_aio_req;
/* check if any pending requests on the atomic list */
A if (!INK_ATOMICLIST_EMPTY(my_aio_req-aio_temp_list))
aio_move(my_aio_req);
if (!(op = my_aio_req-aio_todo.pop()) !(op =
my_aio_req-http_aio_todo.pop()))
Bbreak;
...
service request
...
} while (1);
Cink_cond_wait(my_aio_req-aio_cond, my_aio_req-aio_mutex);
}
...
}
static void
aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
{
...
if (!ink_mutex_try_acquire(req-aio_mutex)) {
Dink_atomiclist_push(req-aio_temp_list, op);
} else {
/* check if any pending requests on the atomic list */
if (!INK_ATOMICLIST_EMPTY(req-aio_temp_list))
aio_move(req);
/* now put the new request */
aio_insert(op, req);
ink_cond_signal(req-aio_cond);
ink_mutex_release(req-aio_mutex);
}
...
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1006) memory management, cut down memory waste ?
[
https://issues.apache.org/jira/browse/TS-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1006:
--
Fix Version/s: (was: 3.5.0)
3.3.4
memory management, cut down memory waste ?
--
Key: TS-1006
URL: https://issues.apache.org/jira/browse/TS-1006
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.1.1
Reporter: Zhao Yongming
Assignee: Yunkai Zhang
Fix For: 3.3.4
Attachments:
0001-TS-1006-Add-an-enable-reclaimable-freelist-option.patch,
0002-TS-1006-Add-a-new-wrapper-ink_atomic_decrement.patch,
0003-TS-1006-Introduce-a-reclaimable-InkFreeList.patch,
0004-TS-1006-Make-InkFreeList-memory-pool-configurable.patch,
Memory-Usage-After-Introduced-New-Allocator.png, memusage.ods, memusage.ods
when we review the memory usage in the production, there is something
abnormal, ie, looks like TS take much memory than index data + common system
waste, and here is some memory dump result by set
proxy.config.dump_mem_info_frequency
1, the one on a not so busy forwarding system:
physics memory: 32G
RAM cache: 22G
DISK: 6140 GB
average_object_size 64000
{code}
allocated |in-use | type size | free list name
|||--
671088640 | 37748736 |2097152 |
memory/ioBufAllocator[14]
2248146944 | 2135949312 |1048576 |
memory/ioBufAllocator[13]
1711276032 | 1705508864 | 524288 |
memory/ioBufAllocator[12]
1669332992 | 1667760128 | 262144 |
memory/ioBufAllocator[11]
2214592512 | 221184 | 131072 |
memory/ioBufAllocator[10]
2325741568 | 2323775488 | 65536 |
memory/ioBufAllocator[9]
2091909120 | 2089123840 | 32768 |
memory/ioBufAllocator[8]
1956642816 | 1956478976 | 16384 |
memory/ioBufAllocator[7]
2094530560 | 2094071808 | 8192 |
memory/ioBufAllocator[6]
356515840 | 355540992 | 4096 |
memory/ioBufAllocator[5]
1048576 | 14336 | 2048 |
memory/ioBufAllocator[4]
131072 | 0 | 1024 |
memory/ioBufAllocator[3]
65536 | 0 |512 |
memory/ioBufAllocator[2]
32768 | 0 |256 |
memory/ioBufAllocator[1]
16384 | 0 |128 |
memory/ioBufAllocator[0]
0 | 0 |576 |
memory/ICPRequestCont_allocator
0 | 0 |112 |
memory/ICPPeerReadContAllocator
0 | 0 |432 |
memory/PeerReadDataAllocator
0 | 0 | 32 |
memory/MIMEFieldSDKHandle
0 | 0 |240 |
memory/INKVConnAllocator
0 | 0 | 96 |
memory/INKContAllocator
4096 | 0 | 32 |
memory/apiHookAllocator
0 | 0 |288 |
memory/FetchSMAllocator
0 | 0 | 80 |
memory/prefetchLockHandlerAllocator
0 | 0 |176 |
memory/PrefetchBlasterAllocator
0 | 0 | 80 |
memory/prefetchUrlBlaster
0 | 0 | 96 | memory/blasterUrlList
0 | 0 | 96 |
memory/prefetchUrlEntryAllocator
0 | 0 |128 |
memory/socksProxyAllocator
0 | 0 |144 |
memory/ObjectReloadCont
3258368 | 576016 |592 |
memory/httpClientSessionAllocator
825344 | 139568 |208 |
memory/httpServerSessionAllocator
22597632 |1284848 | 9808 | memory/httpSMAllocator
0 | 0 | 32 |
memory/CacheLookupHttpConfigAllocator
0 | 0 | 9856 |
memory/httpUpdateSMAllocator
0 | 0 |128 |
memory/RemapPluginsAlloc
0 | 0 | 48 |
memory/CongestRequestParamAllocator
0 | 0 |128 |
memory/CongestionDBContAllocator
5767168 | 704512 | 2048 | memory/hdrStrHeap
18350080 |1153024 | 2048 | memory/hdrHeap
[jira] [Updated] (TS-1099) review of squid replacement algorithm
[ https://issues.apache.org/jira/browse/TS-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1099: -- Fix Version/s: (was: Doc 3.4) review of squid replacement algorithm - Key: TS-1099 URL: https://issues.apache.org/jira/browse/TS-1099 Project: Traffic Server Issue Type: Sub-task Components: Plugins Reporter: Eric Ahn Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1290) the init script patch in RPM
[ https://issues.apache.org/jira/browse/TS-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1290. --- Resolution: Invalid Fix Version/s: (was: 3.5.0) No idea what this is, and no comments answered. Closing. the init script patch in RPM Key: TS-1290 URL: https://issues.apache.org/jira/browse/TS-1290 Project: Traffic Server Issue Type: Improvement Components: Portability Affects Versions: 3.3.0 Reporter: Zhao Yongming Assignee: Leif Hedstrom Priority: Minor we have a patch in the RPM, should we put it in the git master? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-832) Crash Report: RecMessageMarshal_Realloc in cluster mode 2
[
https://issues.apache.org/jira/browse/TS-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming resolved TS-832.
--
Resolution: Cannot Reproduce
Fix Version/s: 3.3.5
Assignee: Zhao Yongming
reopen if it still valid
Crash Report: RecMessageMarshal_Realloc in cluster mode 2
-
Key: TS-832
URL: https://issues.apache.org/jira/browse/TS-832
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Core
Affects Versions: 3.1.0
Environment: version trunk, aka v3.0 after, cluster mode set to 2(
management cluster ), --enable-debug
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Labels: cluster, realloc
Fix For: 3.3.5, 3.5.0
here is two core dumps:
{code}
#0 0x003c33030265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x003c33030265 in raise () from /lib64/libc.so.6
#1 0x003c33031d10 in abort () from /lib64/libc.so.6
#2 0x003c3306a84b in __libc_message () from /lib64/libc.so.6
#3 0x003c33075421 in realloc () from /lib64/libc.so.6
#4 0x2acf28ff4e01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2acf29248f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x20034150, event=1,
e=0x20033d30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x20034150,
event=1, data=0x20033d30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x200441b0) at
Thread.cc:88
#11 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x003c330d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x41f4c3e0:
rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
called by frame at 0x41f4c520
Arglist at 0x41f4c3d0, args:
Locals at 0x41f4c3d0, Previous frame's sp is 0x41f4c3e0
Saved registers:
rip at 0x41f4c3d8
{code}
{code}
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0038aa230265 in raise () from /lib64/libc.so.6
#1 0x0038aa231d10 in abort () from /lib64/libc.so.6
#2 0x0038aa26a84b in __libc_message () from /lib64/libc.so.6
#3 0x0038aa275421 in realloc () from /lib64/libc.so.6
#4 0x2ab28042ce01 in ink_realloc (ptr=Could not find the frame base
for ink_realloc.
) at ink_memory.cc:88
#5 0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010,
record=0x2ab280680f50) at RecMessage.cc:350
#6 0x006eced8 in send_push_message () at P_RecCore.i:154
#7 0x006efef9 in sync_cont::sync (this=0x16a6f150, event=1,
e=0x16a6ed30) at RecProcess.cc:263
#8 0x004d2c5f in Continuation::handleEvent (this=0x16a6f150,
event=1, data=0x16a6ed30) at I_Continuation.h:146
#9 0x006f5f0b in EThread::execute (this=0x2b5d5010) at
UnixEThread.cc:287
#10 0x006f5181 in spawn_thread_internal (a=0x16a7f1b0) at
Thread.cc:88
#11 0x0038aae064a7 in start_thread () from /lib64/libpthread.so.0
#12 0x0038aa2d3c2d in clone () from /lib64/libc.so.6
(gdb) info f
Stack level 0, frame at 0x406b03e0:
rip = 0x38aa230265 in raise; saved rip 0x38aa231d10
called by frame at 0x406b0520
Arglist at 0x406b03d0, args:
Locals at 0x406b03d0, Previous frame's sp is 0x406b03e0
Saved registers:
rip at 0x406b03d8
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1885) autoconf_port doesn't obey incoming_ip_to_bind
[ https://issues.apache.org/jira/browse/TS-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726531#comment-13726531 ] James Peach commented on TS-1885: - We should also only bind localhost. autoconf_port doesn't obey incoming_ip_to_bind -- Key: TS-1885 URL: https://issues.apache.org/jira/browse/TS-1885 Project: Traffic Server Issue Type: Bug Reporter: Ebrahim Mohammadi proxy.config.admin.autoconf_port doesn't obey proxy.local.incoming_ip_to_bind and continues to bind on 0.0.0.0 even though incoming_ip_to_bind is 127.0.0.1. Seen on 3.2.4 trafficserver package of Debian sid installed on a Debian wheezy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1976) Invalid httpport argument passed from traffic_manager to traffic_server
[
https://issues.apache.org/jira/browse/TS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726572#comment-13726572
]
ASF subversion and git services commented on TS-1976:
-
Commit 1c7aa30004741dd94cd56ecfe02648c7f47e2b8c in branch refs/heads/master
from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1c7aa30 ]
TS-1976: Failure to terminate option string in traffic_manager
Invalid httpport argument passed from traffic_manager to traffic_server
---
Key: TS-1976
URL: https://issues.apache.org/jira/browse/TS-1976
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Management, Security
Reporter: Thach Tran
Assignee: James Peach
Fix For: 3.3.5
I'm seeing a weird issue with invalid {{httpport}} option being passed from
{{traffic_manager}} to {{traffic_server}} process. My ps output look a bit
like this (I'm only running {{traffic_manager}} and not {{traffic_cop}})
{noformat}
ats 27565 0.0 0.2 374712 16176 pts/0Sl 14:32 0:00
/trafficserver/bin/traffic_manager
ats 27574 1.7 0.8 569440 52036 pts/0Sl 14:32 0:03
/trafficserver/bin/traffic_server -M --httpport
ip-in=[10.50.156.251]:443:fd=15:ssl,8443:fd=16:ssl?ݻ?
{noformat}
Notice some garbage characters at the end of {{traffic_server}}'s
{{httpport}} arg. That also reflects in the log as follows.
{noformat}
WARNING: Invalid option 'ssl�ݻ' in port configuration '8443:fd=16:ssl�ݻ'
{noformat}
My server_ports in records.config is as follows.
{noformat}
CONFIG proxy.config.http.server_ports STRING
ssl:443:ip-in=[10.50.156.251],ssl:8443
{noformat}
After spending some time looking at the code in {{LocalManager::startProxy}}
({{LocalManager.cc:1037}}), I believe the char {{Vec}} namely
{{real_proxy_options}} is not being null-terminated despite the attempt of
doing so in line 1037.
{code}
// NUL-terminate for the benefit of strtok and printf.
real_proxy_options.append('\0');
{code}
This is, I think, because of the {{Vec}}'s implementation of appending from
another {{Vec}} which explicitly check for if an element is 0 then don't
append that element (line 352 in {{lib/ts/Vec.h}}).
{code}
template class C, class A, int S inline void
VecC,A,S::append(const VecC vv) {
for (C *c = vv.v; c vv.v + vv.n; c++)
if (*c != 0)
add(*c);
}
{code}
I have no idea why the implementation of {{Vec}} is that way but I would
think it's probably safer not messing around with a container class that has
been used in many other places. So, my suggestion would be something like
this in {{LocalManager}}.
{code}
// NUL-terminate for the benefit of strtok and printf.
real_proxy_options.append(, 1);
{code}
Any thought would be very welcome.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1976) Invalid httpport argument passed from traffic_manager to traffic_server
[
https://issues.apache.org/jira/browse/TS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726575#comment-13726575
]
Alan M. Carroll commented on TS-1976:
-
I checked this in the debugger and it works (add a nul byte to terminate). I
want to thank Thach for his detective work and commit - very helpful.
Invalid httpport argument passed from traffic_manager to traffic_server
---
Key: TS-1976
URL: https://issues.apache.org/jira/browse/TS-1976
Project: Traffic Server
Issue Type: Bug
Components: Configuration, Management, Security
Reporter: Thach Tran
Assignee: James Peach
Fix For: 3.3.5
I'm seeing a weird issue with invalid {{httpport}} option being passed from
{{traffic_manager}} to {{traffic_server}} process. My ps output look a bit
like this (I'm only running {{traffic_manager}} and not {{traffic_cop}})
{noformat}
ats 27565 0.0 0.2 374712 16176 pts/0Sl 14:32 0:00
/trafficserver/bin/traffic_manager
ats 27574 1.7 0.8 569440 52036 pts/0Sl 14:32 0:03
/trafficserver/bin/traffic_server -M --httpport
ip-in=[10.50.156.251]:443:fd=15:ssl,8443:fd=16:ssl?ݻ?
{noformat}
Notice some garbage characters at the end of {{traffic_server}}'s
{{httpport}} arg. That also reflects in the log as follows.
{noformat}
WARNING: Invalid option 'ssl�ݻ' in port configuration '8443:fd=16:ssl�ݻ'
{noformat}
My server_ports in records.config is as follows.
{noformat}
CONFIG proxy.config.http.server_ports STRING
ssl:443:ip-in=[10.50.156.251],ssl:8443
{noformat}
After spending some time looking at the code in {{LocalManager::startProxy}}
({{LocalManager.cc:1037}}), I believe the char {{Vec}} namely
{{real_proxy_options}} is not being null-terminated despite the attempt of
doing so in line 1037.
{code}
// NUL-terminate for the benefit of strtok and printf.
real_proxy_options.append('\0');
{code}
This is, I think, because of the {{Vec}}'s implementation of appending from
another {{Vec}} which explicitly check for if an element is 0 then don't
append that element (line 352 in {{lib/ts/Vec.h}}).
{code}
template class C, class A, int S inline void
VecC,A,S::append(const VecC vv) {
for (C *c = vv.v; c vv.v + vv.n; c++)
if (*c != 0)
add(*c);
}
{code}
I have no idea why the implementation of {{Vec}} is that way but I would
think it's probably safer not messing around with a container class that has
been used in many other places. So, my suggestion would be something like
this in {{LocalManager}}.
{code}
// NUL-terminate for the benefit of strtok and printf.
real_proxy_options.append(, 1);
{code}
Any thought would be very welcome.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2088) Change TSRecordType enum values to powers of two
Phil Sorber created TS-2088: --- Summary: Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2088: Labels: C (was: ) Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2088: Priority: Minor (was: Major) Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-2088: Fix Version/s: 3.5.1 Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber reassigned TS-2088: --- Assignee: Phil Sorber Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1255) Add more overridable records.config configurations
[
https://issues.apache.org/jira/browse/TS-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726863#comment-13726863
]
ASF subversion and git services commented on TS-1255:
-
Commit f047b43ecd68d107ef8d904e6afe1415fc6507f0 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f047b43 ]
TS-1255 Fix the types for all overridable configs. This was actually a real bug
in the code,
in that all float configurations were actually treated as integer, rendering
them useless
Add more overridable records.config configurations
--
Key: TS-1255
URL: https://issues.apache.org/jira/browse/TS-1255
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: A
Fix For: 3.3.5
We should examine at least the following configs, and see which ones can (or
can not) be moved to be overridable:
{code}
MgmtInt server_max_connections;
MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought
to be overridable, but difficult right now.
char *proxy_request_via_string;
int proxy_request_via_string_len;
char *proxy_response_via_string;
int proxy_response_via_string_len;
MgmtInt origin_server_pipeline;
MgmtInt user_agent_pipeline;
MgmtInt transaction_active_timeout_in;
MgmtInt accept_no_activity_timeout;
MgmtInt background_fill_active_timeout;
MgmtFloat background_fill_threshold;
MgmtInt parent_connect_attempts;
MgmtInt per_parent_connect_attempts;
MgmtInt parent_connect_timeout;
MgmtByte insert_age_in_response;
MgmtByte avoid_content_spoofing;
MgmtByte enable_http_stats;
MgmtInt max_cache_open_write_retries;
MgmtByte cache_enable_default_vary_headers;
MgmtByte cache_when_to_add_no_cache_to_msie_requests;
MgmtByte cache_range_lookup;
MgmtInt request_hdr_max_size;
MgmtInt response_hdr_max_size;
MgmtByte push_method_enabled;
MgmtByte referer_filter_enabled;
MgmtByte referer_format_redirect;
MgmtByte accept_encoding_filter_enabled;
// WTF!!! Bool ???
/// Accept connections on foreign addresses.
bool client_transparency_enabled;
/// Use client address to connect to origin server.
bool server_transparency_enabled;
MgmtByte negative_revalidating_enabled;
MgmtInt negative_revalidating_lifetime;
MgmtByte ignore_accept_mismatch;
MgmtByte ignore_accept_language_mismatch;
MgmtByte ignore_accept_encoding_mismatch;
MgmtByte ignore_accept_charset_mismatch;
// Optimize gzip alternates //
MgmtByte normalize_ae_gzip;
{code}
Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
just get 3.1.4/3.2 done sooner rather than later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1255) Add more overridable records.config configurations
[
https://issues.apache.org/jira/browse/TS-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726864#comment-13726864
]
ASF subversion and git services commented on TS-1255:
-
Commit cba930314ee4a41ce7c9e64e6eeffcc938503447 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cba9303 ]
TS-1255 Added new configs to plugin docs.
Add more overridable records.config configurations
--
Key: TS-1255
URL: https://issues.apache.org/jira/browse/TS-1255
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: A
Fix For: 3.3.5
We should examine at least the following configs, and see which ones can (or
can not) be moved to be overridable:
{code}
MgmtInt server_max_connections;
MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought
to be overridable, but difficult right now.
char *proxy_request_via_string;
int proxy_request_via_string_len;
char *proxy_response_via_string;
int proxy_response_via_string_len;
MgmtInt origin_server_pipeline;
MgmtInt user_agent_pipeline;
MgmtInt transaction_active_timeout_in;
MgmtInt accept_no_activity_timeout;
MgmtInt background_fill_active_timeout;
MgmtFloat background_fill_threshold;
MgmtInt parent_connect_attempts;
MgmtInt per_parent_connect_attempts;
MgmtInt parent_connect_timeout;
MgmtByte insert_age_in_response;
MgmtByte avoid_content_spoofing;
MgmtByte enable_http_stats;
MgmtInt max_cache_open_write_retries;
MgmtByte cache_enable_default_vary_headers;
MgmtByte cache_when_to_add_no_cache_to_msie_requests;
MgmtByte cache_range_lookup;
MgmtInt request_hdr_max_size;
MgmtInt response_hdr_max_size;
MgmtByte push_method_enabled;
MgmtByte referer_filter_enabled;
MgmtByte referer_format_redirect;
MgmtByte accept_encoding_filter_enabled;
// WTF!!! Bool ???
/// Accept connections on foreign addresses.
bool client_transparency_enabled;
/// Use client address to connect to origin server.
bool server_transparency_enabled;
MgmtByte negative_revalidating_enabled;
MgmtInt negative_revalidating_lifetime;
MgmtByte ignore_accept_mismatch;
MgmtByte ignore_accept_language_mismatch;
MgmtByte ignore_accept_encoding_mismatch;
MgmtByte ignore_accept_charset_mismatch;
// Optimize gzip alternates //
MgmtByte normalize_ae_gzip;
{code}
Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
just get 3.1.4/3.2 done sooner rather than later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1255) Add more overridable records.config configurations
[
https://issues.apache.org/jira/browse/TS-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726865#comment-13726865
]
ASF subversion and git services commented on TS-1255:
-
Commit 73b277f6dc56fc61c27e56c14266e60091e48637 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=73b277f ]
TS-1255 Added accept-encoding filter to overridable configs
Add more overridable records.config configurations
--
Key: TS-1255
URL: https://issues.apache.org/jira/browse/TS-1255
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: A
Fix For: 3.3.5
We should examine at least the following configs, and see which ones can (or
can not) be moved to be overridable:
{code}
MgmtInt server_max_connections;
MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought
to be overridable, but difficult right now.
char *proxy_request_via_string;
int proxy_request_via_string_len;
char *proxy_response_via_string;
int proxy_response_via_string_len;
MgmtInt origin_server_pipeline;
MgmtInt user_agent_pipeline;
MgmtInt transaction_active_timeout_in;
MgmtInt accept_no_activity_timeout;
MgmtInt background_fill_active_timeout;
MgmtFloat background_fill_threshold;
MgmtInt parent_connect_attempts;
MgmtInt per_parent_connect_attempts;
MgmtInt parent_connect_timeout;
MgmtByte insert_age_in_response;
MgmtByte avoid_content_spoofing;
MgmtByte enable_http_stats;
MgmtInt max_cache_open_write_retries;
MgmtByte cache_enable_default_vary_headers;
MgmtByte cache_when_to_add_no_cache_to_msie_requests;
MgmtByte cache_range_lookup;
MgmtInt request_hdr_max_size;
MgmtInt response_hdr_max_size;
MgmtByte push_method_enabled;
MgmtByte referer_filter_enabled;
MgmtByte referer_format_redirect;
MgmtByte accept_encoding_filter_enabled;
// WTF!!! Bool ???
/// Accept connections on foreign addresses.
bool client_transparency_enabled;
/// Use client address to connect to origin server.
bool server_transparency_enabled;
MgmtByte negative_revalidating_enabled;
MgmtInt negative_revalidating_lifetime;
MgmtByte ignore_accept_mismatch;
MgmtByte ignore_accept_language_mismatch;
MgmtByte ignore_accept_encoding_mismatch;
MgmtByte ignore_accept_charset_mismatch;
// Optimize gzip alternates //
MgmtByte normalize_ae_gzip;
{code}
Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
just get 3.1.4/3.2 done sooner rather than later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1255) Add more overridable records.config configurations
[
https://issues.apache.org/jira/browse/TS-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726866#comment-13726866
]
ASF subversion and git services commented on TS-1255:
-
Commit ec65b1193fcb9bcd6ee2150160c94d6825a85a25 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ec65b11 ]
TS-1255 Add negative revalidation as overridable configs, and cleanup
Add more overridable records.config configurations
--
Key: TS-1255
URL: https://issues.apache.org/jira/browse/TS-1255
Project: Traffic Server
Issue Type: Improvement
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: A
Fix For: 3.3.5
We should examine at least the following configs, and see which ones can (or
can not) be moved to be overridable:
{code}
MgmtInt server_max_connections;
MgmtInt origin_min_keep_alive_connections; // TODO: This one really ought
to be overridable, but difficult right now.
char *proxy_request_via_string;
int proxy_request_via_string_len;
char *proxy_response_via_string;
int proxy_response_via_string_len;
MgmtInt origin_server_pipeline;
MgmtInt user_agent_pipeline;
MgmtInt transaction_active_timeout_in;
MgmtInt accept_no_activity_timeout;
MgmtInt background_fill_active_timeout;
MgmtFloat background_fill_threshold;
MgmtInt parent_connect_attempts;
MgmtInt per_parent_connect_attempts;
MgmtInt parent_connect_timeout;
MgmtByte insert_age_in_response;
MgmtByte avoid_content_spoofing;
MgmtByte enable_http_stats;
MgmtInt max_cache_open_write_retries;
MgmtByte cache_enable_default_vary_headers;
MgmtByte cache_when_to_add_no_cache_to_msie_requests;
MgmtByte cache_range_lookup;
MgmtInt request_hdr_max_size;
MgmtInt response_hdr_max_size;
MgmtByte push_method_enabled;
MgmtByte referer_filter_enabled;
MgmtByte referer_format_redirect;
MgmtByte accept_encoding_filter_enabled;
// WTF!!! Bool ???
/// Accept connections on foreign addresses.
bool client_transparency_enabled;
/// Use client address to connect to origin server.
bool server_transparency_enabled;
MgmtByte negative_revalidating_enabled;
MgmtInt negative_revalidating_lifetime;
MgmtByte ignore_accept_mismatch;
MgmtByte ignore_accept_language_mismatch;
MgmtByte ignore_accept_encoding_mismatch;
MgmtByte ignore_accept_charset_mismatch;
// Optimize gzip alternates //
MgmtByte normalize_ae_gzip;
{code}
Marking this for v3.3.0, it'd be nice to get into 3.2, but I rather have us
just get 3.1.4/3.2 done sooner rather than later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726878#comment-13726878 ] James Peach commented on TS-2088: - This is source compatible but not binary compatible. Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726880#comment-13726880
]
Igor Galić commented on TS-1953:
{code}
/* hideous sample code. Pretty sure we can do better */
bool
TSVersionGE(int major, int minor = -1, int patch = -1) {
if ( !(TSTrafficServerVersionGetMajor = major)) {
return false;
} else if (minor != -1) {
if ( !(TSTrafficServerVersionGetMinor = minor)) {
return false;
} else if (patch != -1 ) {
if ( !(TSTrafficServerVersionGetPatch = patch)) {
return false;
}
}
}
return true;
}
{code}
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726879#comment-13726879 ] James Peach commented on TS-2088: - I'm not sure how this makes sense. What would you use this for? Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726880#comment-13726880
]
Igor Galić edited comment on TS-1953 at 8/1/13 9:18 PM:
{code}
bool
TSVersionGE(int major, int minor = -1, int patch = -1)
{
if (!(TS_MAJOR = major)){
return false;
}
if (minor != -1 !(TS_MINOR = minor)) {
return false;
}
if (patch != -1 !(TS_PATCH = patch)) {
return false;
}
return true;
}
{code}
was (Author: i.galic):
{code}
/* hideous sample code. Pretty sure we can do better */
bool
TSVersionGE(int major, int minor = -1, int patch = -1) {
if ( !(TSTrafficServerVersionGetMajor = major)) {
return false;
} else if (minor != -1) {
if ( !(TSTrafficServerVersionGetMinor = minor)) {
return false;
} else if (patch != -1 ) {
if ( !(TSTrafficServerVersionGetPatch = patch)) {
return false;
}
}
}
return true;
}
{code}
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726913#comment-13726913
]
Igor Galić commented on TS-1953:
{code}
bool
TSVersionLE(int major, int minor = -1, int patch = -1)
{
if (!(TS_MAJOR = major)){
return false;
}
if (minor != -1 !(TS_MINOR = minor)) {
return false;
}
if (patch != -1 !(TS_PATCH = patch)) {
return false;
}
return true;
}
{code}
I think adding these two should suffice to save us from lots of repetitive
boiler code.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726880#comment-13726880
]
Igor Galić edited comment on TS-1953 at 8/1/13 9:28 PM:
{code}
bool
TSVersionGE(int major, int minor = 0, int patch = 0)
{
if (!(TS_MAJOR = major)){
return false;
}
if (!(TS_MINOR = minor)) {
return false;
}
if (!(TS_PATCH = patch)) {
return false;
}
return true;
}
{code}
was (Author: i.galic):
{code}
bool
TSVersionGE(int major, int minor = -1, int patch = -1)
{
if (!(TS_MAJOR = major)){
return false;
}
if (minor != -1 !(TS_MINOR = minor)) {
return false;
}
if (patch != -1 !(TS_PATCH = patch)) {
return false;
}
return true;
}
{code}
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726913#comment-13726913
]
Igor Galić edited comment on TS-1953 at 8/1/13 9:28 PM:
{code}
bool
TSVersionLE(int major, int minor = INT_MAX, int patch = INT_MAX)
{
if (!(TS_MAJOR = major)){
return false;
}
if (!(TS_MINOR = minor)) {
return false;
}
if (!(TS_PATCH = patch)) {
return false;
}
return true;
}
{code}
I think adding these two should suffice to save us from lots of repetitive
boiler code.
was (Author: i.galic):
{code}
bool
TSVersionLE(int major, int minor = -1, int patch = -1)
{
if (!(TS_MAJOR = major)){
return false;
}
if (minor != -1 !(TS_MINOR = minor)) {
return false;
}
if (patch != -1 !(TS_PATCH = patch)) {
return false;
}
return true;
}
{code}
I think adding these two should suffice to save us from lots of repetitive
boiler code.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726923#comment-13726923
]
James Peach commented on TS-1953:
-
I'd just remove the check from the example. Hardly any plugin *really* cares
about this AFAICT.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726950#comment-13726950
]
Igor Galić commented on TS-1953:
given that how check_ts_version() is currently used, most plugins will fail to
compile anyway, so it's not useful.
Perhaps we should expose {{TS_VERSION_*}} so plugin developers can {{#ifdef}}
around different versions.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1685) configure --enable-micro doesn't build
[ https://issues.apache.org/jira/browse/TS-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726962#comment-13726962 ] ASF subversion and git services commented on TS-1685: - Commit 5b80237d7f05ecc12463094e463eb15564073a7b in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5b80237 ] Added TS-1685 configure --enable-micro doesn't build -- Key: TS-1685 URL: https://issues.apache.org/jira/browse/TS-1685 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: Leif Hedstrom Fix For: 3.3.5 The --enable-micro build configuration doesn't build. We should remove this and any dependent compilation options. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1685) configure --enable-micro doesn't build
[ https://issues.apache.org/jira/browse/TS-1685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726963#comment-13726963 ] ASF subversion and git services commented on TS-1685: - Commit b4d411e07953fd3a7f9bea60f4c822360658a1aa in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b4d411e ] TS-1685 Remove TS_MICRO and fellas configure --enable-micro doesn't build -- Key: TS-1685 URL: https://issues.apache.org/jira/browse/TS-1685 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: Leif Hedstrom Fix For: 3.3.5 The --enable-micro build configuration doesn't build. We should remove this and any dependent compilation options. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2086) Remove a few completely unused RecordsConfig.cc settings
[
https://issues.apache.org/jira/browse/TS-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726971#comment-13726971
]
ASF subversion and git services commented on TS-2086:
-
Commit 0520723ac42f5b01b068d3762971b4dd4648cfc9 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0520723 ]
TS-2086 Remove a few more unused configs
Remove a few completely unused RecordsConfig.cc settings
Key: TS-2086
URL: https://issues.apache.org/jira/browse/TS-2086
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.5
Found a few more:
{code}
proxy.config.temp_dir
proxy.config.cli_binary
proxy.config.cop_name
proxy.config.manager_name
proxy.config.process_state_dump_mode
proxy.config.server_name
proxy.config.start_script
proxy.config.watch_script
proxy.config.history_info_enabled
{code}
They are truly no-ops (have no purpose). There were a few more (such as
Product name and Vendor), which I left cause they might have some use as
part of a monitoring system.
Please speak up now if you feel any of these do deserve to linger, even
unused. The reason to remove them is to avoid confusing, such as thinking
changing them would have some sort of effect (which neither does).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2077) Remove proxy.config.http.user_agent_pipeline remnants
[ https://issues.apache.org/jira/browse/TS-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2077: -- Fix Version/s: (was: 3.3.5) 3.3.6 Remove proxy.config.http.user_agent_pipeline remnants - Key: TS-2077 URL: https://issues.apache.org/jira/browse/TS-2077 Project: Traffic Server Issue Type: Bug Components: Configuration, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.6 As it turns out, this configuration doesn't actually do *anything*. It's a completely unused (and unfortunately) unusuable configuration. I think removing it (for now) is better, until we actually either need it or do something useful with it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726989#comment-13726989
]
ASF subversion and git services commented on TS-1953:
-
Commit be8fd6cd87e6a9b4a00c7f13bd5573165ad09103 in branch refs/heads/master
from [~i.galic]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=be8fd6c ]
TS-1953: remove version check from stable plugins
we're closing the night with a cleanup in the stable plugins.
Thanks, You've been a great crowd.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726990#comment-13726990
]
ASF subversion and git services commented on TS-1953:
-
Commit a8febbf50fecd6707e450d65febac27734b0864f in branch refs/heads/master
from [~i.galic]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a8febbf ]
TS-1953: Remove check_ts_version() from experimental plugins
more axing: This time around, plugins/experimental.
i'm noticing that we do expose TS_VERSION, so ignore most of my last
commit message ;)
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13726991#comment-13726991
]
ASF subversion and git services commented on TS-1953:
-
Commit 5b8b96850137ed29905fd1c244b4c6da3a3b02e2 in branch refs/heads/master
from [~i.galic]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5b8b968 ]
TS-1953: remove check_ts_version() from examples
remove the boilerplate check_ts_version() function call from all
examples. This function is nice in a specific example, but it does not
make sense to have it in every single example plugin.
Since the code is compiled, in most cases that's too late to catch
issues with API versions, so it doesn't make sense to begin with.
In order to enable Plugin Developers to do such checks, and #ifdef
around API issues, we'd have to expose the TS_VERSION_* contants.
n.b.: We might want add one example which shows off how to use the
TSTrafficServerGetVersion() API, but we have that in the man page now
anyway.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727021#comment-13727021
]
Igor Galić commented on TS-1953:
I'll close this up when I'm awake and sure that it's also axed (mostly) from
the docs.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727087#comment-13727087 ] Phil Sorber commented on TS-2088: - Not binary compatible, but it's meant for 3.5, and you won't need to change any plugin code. Right now if you are doing TSRecordsDump() you have to pick the record type. There is no ALL and no way to combine them other than making the call multiple times. There is also code changes needed in TSRecordsDump() obviously. Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727091#comment-13727091 ] James Peach commented on TS-2088: - Does this one use case outweigh the ambiguity that this would introduce everywhere else? Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2077) Remove proxy.config.http.user_agent_pipeline remnants
[ https://issues.apache.org/jira/browse/TS-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727202#comment-13727202 ] Zhao Yongming commented on TS-2077: --- I think that pipeline is supported sometime before, if now we don't, then someone break it? Remove proxy.config.http.user_agent_pipeline remnants - Key: TS-2077 URL: https://issues.apache.org/jira/browse/TS-2077 Project: Traffic Server Issue Type: Bug Components: Configuration, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.6 As it turns out, this configuration doesn't actually do *anything*. It's a completely unused (and unfortunately) unusuable configuration. I think removing it (for now) is better, until we actually either need it or do something useful with it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727207#comment-13727207 ] Phil Sorber commented on TS-2088: - What other ambiguity? Are you suggesting that we need to do this consistently across other enum's that it makes sense for? Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727276#comment-13727276
]
ASF subversion and git services commented on TS-1330:
-
Commit c1c3db9d7b524176e611a6aba3066d1a732b4bd2 in branch refs/heads/t from
[~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c1c3db9 ]
TS-1330: Fix logging core at checkout_write()
== Analysis ==
1. One thread(A) got an LogBuffer object in LogObject::_checkout_write() and ran
into LogBuffer::checkout_write(), before it updated the LogBuffer::m_state,
it was scheduled out by the kernel.
2. Other threads got the same LogBuffer object, but they all finished
_checkout_write() codes and made the LogBuffer object become full, finally
one of these thread flushed the LogBuffer object into write_list queue.
3. The LogBuffer object's m_references == 0 at this time.
4. The flushing thread would call LogBufferManager::flush_buffers() to loop
write_list. As the LogBuffer's m_references == 0, so it would be flushed
and deleted.
5. Now, thread(A) would be scheduled in by the kernel, but the LogBuffer object
has been deleted, so the m_buffer == NULL, that is why entry_header is 0x0.
== Solution ==
1. Remove flushing code from LogObject::log(), we should flush LogBuffer into
queue only when new_buffer is created, so that we can promise that LogBuffer
must be flushed only once.
2. The flushing thread should both check m_references and m_state.s.num_writers.
3. When allocate a new_buffer, should avoid memory leak.
Signed-off-by: Yunkai Zhang qiushu@taobao.com
Logging related segfault in 3.2.0
-
Key: TS-1330
URL: https://issues.apache.org/jira/browse/TS-1330
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: ATS 3.2.0 on RHEL 6.2 64-bit
Reporter: David Carlin
Assignee: Yunkai Zhang
Priority: Critical
Labels: A, crash
Fix For: 3.3.5
Attachments: 0001-A-testing-patch-to-verify-my-analysis.patch,
0001-TS-1330-Fix-logging-core-at-checkout_write.patch,
0001-TS-1330-Fix-logging-core-at-checkout_write.patch.V2
I observed the following crash once on one of our ATS boxes - possibly
related to TS-1240
Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
0058e083 sp 2b0a2982b740 error 6
Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
system error 104: Connection reset by peer)
Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
system error 32: Broken pipe)
Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
[25826 35584]
Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
sure traffic_server is dead
Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:12)
Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
/home/y/logs/trafficserver/manager.log
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:31)
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
/home/y/logs/trafficserver/diags.log
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
insert duplicate!
Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
[Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
[jira] [Commented] (TS-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727281#comment-13727281
]
ASF subversion and git services commented on TS-1330:
-
Commit 3e05261c675b15a76f178e1d3e579c6941f42d20 in branch refs/heads/master
from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3e05261 ]
TS-1330: Fix logging core at checkout_write()
== Analysis ==
1. One thread(A) got an LogBuffer object in LogObject::_checkout_write() and ran
into LogBuffer::checkout_write(), before it updated the LogBuffer::m_state,
it was scheduled out by the kernel.
2. Other threads got the same LogBuffer object, but they all finished
_checkout_write() codes and made the LogBuffer object become full, finally
one of these thread flushed the LogBuffer object into write_list queue.
3. The LogBuffer object's m_references == 0 at this time.
4. The flushing thread would call LogBufferManager::flush_buffers() to loop
write_list. As the LogBuffer's m_references == 0, so it would be flushed
and deleted.
5. Now, thread(A) would be scheduled in by the kernel, but the LogBuffer object
has been deleted, so the m_buffer == NULL, that is why entry_header is 0x0.
== Solution ==
1. Remove flushing code from LogObject::log(), we should flush LogBuffer into
queue only when new_buffer is created, so that we can promise that LogBuffer
must be flushed only once.
2. The flushing thread should both check m_references and m_state.s.num_writers.
3. When allocate a new_buffer, should avoid memory leak.
Signed-off-by: Yunkai Zhang qiushu@taobao.com
Logging related segfault in 3.2.0
-
Key: TS-1330
URL: https://issues.apache.org/jira/browse/TS-1330
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: ATS 3.2.0 on RHEL 6.2 64-bit
Reporter: David Carlin
Assignee: Yunkai Zhang
Priority: Critical
Labels: A, crash
Fix For: 3.3.5
Attachments: 0001-A-testing-patch-to-verify-my-analysis.patch,
0001-TS-1330-Fix-logging-core-at-checkout_write.patch,
0001-TS-1330-Fix-logging-core-at-checkout_write.patch.V2
I observed the following crash once on one of our ATS boxes - possibly
related to TS-1240
Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
0058e083 sp 2b0a2982b740 error 6
Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
system error 104: Connection reset by peer)
Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
system error 32: Broken pipe)
Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
[25826 35584]
Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
sure traffic_server is dead
Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:12)
Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
/home/y/logs/trafficserver/manager.log
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:31)
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
/home/y/logs/trafficserver/diags.log
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
insert duplicate!
Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
[Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by
[jira] [Commented] (TS-2088) Change TSRecordType enum values to powers of two
[ https://issues.apache.org/jira/browse/TS-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727287#comment-13727287 ] James Peach commented on TS-2088: - What do TSMgmtStringCreate() and TSMgmtIntCreate() do when you pass them TS_RECORDTYPE_PROCESS|TS_RECORDTYPE_NODE? I'd support adding a TS_RECORDTYPE_ALL value for use in TSRecordDump, though. Change TSRecordType enum values to powers of two Key: TS-2088 URL: https://issues.apache.org/jira/browse/TS-2088 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber Assignee: Phil Sorber Priority: Minor Labels: C Fix For: 3.5.1 This way we can OR them together and do multiple types at once. Also add an ALL value. This should not effect the API compatibility with old usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727290#comment-13727290
]
Leif Hedstrom commented on TS-1953:
---
I'd leave some examples, and text, in the docs. There are reasons why someone
would want to do this, particularly for a plugin that is outside the docs. And
we should have at least one plugin that uses the TS_VERSION_STRING and/or
TS_VERSION_NUMBER and/or TS_VERSION_{MAJOR,MINOR,mICRO}.
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1953) remove check_ts_version() from (example) plugins or make it an API
[
https://issues.apache.org/jira/browse/TS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727304#comment-13727304
]
James Peach commented on TS-1953:
-
There's a man page which has an example.
https://trafficserver.readthedocs.org/en/latest/reference/api/TSTrafficServerVersionGet.en.html
remove check_ts_version() from (example) plugins or make it an API
--
Key: TS-1953
URL: https://issues.apache.org/jira/browse/TS-1953
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Igor Galić
Fix For: sometime
almost every single of our (example) plugins has a function
{{chec_ts_version()}}. If this boiler-code is so crucial to a plugin's
functionality, we should offer an API for it, instead of making developers
write (copy) that code every time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2077) Remove proxy.config.http.user_agent_pipeline remnants
[ https://issues.apache.org/jira/browse/TS-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727309#comment-13727309 ] Leif Hedstrom commented on TS-2077: --- I don't think so. It's not that we don't support pipelining, we just don't do anything special, and certainly we don't honor the configurations in anyway. I can't see anything that has changed in this area in the last 3-4 years. Bryan Call (bcall): can you check the Yahoo code, and see if we removed something related to the pipelining configuration / support before open sourcing? Remove proxy.config.http.user_agent_pipeline remnants - Key: TS-2077 URL: https://issues.apache.org/jira/browse/TS-2077 Project: Traffic Server Issue Type: Bug Components: Configuration, HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.6 As it turns out, this configuration doesn't actually do *anything*. It's a completely unused (and unfortunately) unusuable configuration. I think removing it (for now) is better, until we actually either need it or do something useful with it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
