[jira] [Updated] (TS-823) Build fails with --enable-standalone-iocore
[
https://issues.apache.org/jira/browse/TS-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-823:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Build fails with --enable-standalone-iocore
> ---
>
> Key: TS-823
> URL: https://issues.apache.org/jira/browse/TS-823
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.1.0, 2.1.8
>Reporter: Igor Galić
> Fix For: 3.2.0
>
>
> When enabling ./configuring the build with --enable-standalone-iocore the
> build fails with:
> {noformat}
> igalic@bawnb976 ~/Projects/asf/trafficserver/iocore/dns (svn)-[trunk:1132769]
> % make
> g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem
> -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb
> -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils
> -I../../iocore/dns -I../../lib/records -D_LARGEFILE64_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux
> -I/usr/include/tcl8.4 -march=native -mtune=native -march=i586 -g -pipe -Wall
> -Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -MT DNS.o -MD -MP -MF .deps/DNS.Tpo -c -o DNS.o DNS.cc
> DNS.cc: In member function 'virtual int DNSProcessor::start(int)':
> DNS.cc:132:7: error: 'SplitDNSConfig' has not been declared
> DNS.cc:134:5: error: 'SplitDNSConfig' has not been declared
> DNS.cc: In member function 'void DNSEntry::init(const char*, int, int,
> Continuation*, DNSHandler*, int)':
> DNS.cc:261:19: error: 'INK_NOWARN' was not declared in this scope
> make: *** [DNS.o] Error 1
> {noformat}
> This is due to missing dependencies in Makefile.am: Even though we include
> "P_DNS.h", which includes "libts.h", which in turn includes "ink_config.h"
> the compiler doesn't seem to be able to resolve "SPLIT_DNS".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-81) Have one single place to store and lookup remap rules irrespective of type
[ https://issues.apache.org/jira/browse/TS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-81: Fix Version/s: (was: 3.1.2) 3.2.0 > Have one single place to store and lookup remap rules irrespective of type > -- > > Key: TS-81 > URL: https://issues.apache.org/jira/browse/TS-81 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0a >Reporter: Manjesh Nilange >Priority: Minor > Fix For: 3.2.0 > > > Currently, remap rules are stored in different structures and looked up > separately based on type (forward, reverse, etc.). It'd be better design and > more maintainable to process (store, search) all rules in one structure and > then use type to determine action. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-754) Reduce memory usage on idle connections
[ https://issues.apache.org/jira/browse/TS-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-754: - Fix Version/s: (was: 3.1.2) 3.2.0 > Reduce memory usage on idle connections > --- > > Key: TS-754 > URL: https://issues.apache.org/jira/browse/TS-754 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > We should examine what memory (if any) can be returned to class allocators / > freelist when a connection is idle (in keep-alive). Right now, I suspect we > hold on to more memory than is necessary, which limits the number of KA > connections a server can have. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-152) Cleanup Diags
[ https://issues.apache.org/jira/browse/TS-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-152: - Fix Version/s: (was: 3.1.2) 3.2.0 > Cleanup Diags > - > > Key: TS-152 > URL: https://issues.apache.org/jira/browse/TS-152 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: John Plevyak >Priority: Minor > Fix For: 3.2.0 > > > The use of Diags functions and tags is inconsistent and they are often > wrapped with > incompatible macros in each module. > Following the discussion in https://issues.apache.org/jira/browse/TS-130 I > propose that we: > 1. use Diags() for diagnostic messages to appear from all builds > 2. use Debug() for diagnostic messages to appear from only DEBUG builds, > replacing this with myriad of competing macros for this behavior in > different moduels > 3. organize the existing tags hierarchically and document then (at least) in > the master P_.h file for > each module. > 4. rename the -T argument form --debug_tags to --diag_tags > 5. remove #define of IOCORE_MacheFatal to fprintf in P_EventSystem.h (what > the heck is that?) >and other wrappers for these functions and standardize them > 6. remove unused and competing ink_error.h/cc functions ink_fatal ink_dprintf > etc. > and convert to the Fatal/Diags versions. >These are all vestiges of when ink_xxx.h were C headers and InkFoo.h were > C++ > headers. Which accounts for the redundancy. > Because "." is special in regex we could use: > cache_write_open > cache_write_ready > etc. > so we could use -T"cache*" or -T"cache_write*" to capture different levels of > events. > Ideas welcome. > john -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-72) Records config review for update type behavior
[ https://issues.apache.org/jira/browse/TS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-72: Fix Version/s: (was: 3.1.2) 3.2.0 > Records config review for update type behavior > -- > > Key: TS-72 > URL: https://issues.apache.org/jira/browse/TS-72 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 2.0.0a > Environment: All >Reporter: George Paul >Priority: Minor > Fix For: 3.2.0 > > > The Records configuration variables need to be reviewed for proper intended > update type behavior. > The update types can be the following: > RU_NULL, // default: don't know the behavior > RU_REREAD,// config can be updated dynamically w/ > traffic_line -x > RU_RESTART_TS,// config requires TS to be restarted to take effect > RU_RESTART_TM, // config requires TM/TS to be restarted to take effect > RU_RESTART_TC // config requires TC/TM/TS to be restarted to take > effect > This will require review of the overall system and component configs. > Possibly split this ticket into seperate tickets targeted to the various > components. > -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-287) transaction_active_timeout_in does not trigger on the first request of a Keep-Alive connection
[ https://issues.apache.org/jira/browse/TS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-287: - Fix Version/s: (was: 3.1.2) 3.2.0 > transaction_active_timeout_in does not trigger on the first request of a > Keep-Alive connection > -- > > Key: TS-287 > URL: https://issues.apache.org/jira/browse/TS-287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Steve Jiang > Fix For: 3.2.0 > > Attachments: slowclient.pl > > > proxy.config.http.transaction_active_timeout_in does not trigger on a slow > request on if the request is the first on a new client connection, because > the timeout event is cancelled before it can be triggered. > Subsequent requests with keep-alive on the same connection will correctly > trigger the active_timeout_in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-380) Remaining 64-bit "conversion"
[ https://issues.apache.org/jira/browse/TS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-380: - Fix Version/s: (was: 3.1.2) 3.2.0 > Remaining 64-bit "conversion" > - > > Key: TS-380 > URL: https://issues.apache.org/jira/browse/TS-380 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Critical > Fix For: 3.2.0 > > > There are a few areas which still needs to some 'lovin for true 64-bit > support. In particular, I know of an area in logging, related to log > filtering, that needs to be modified. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-119) RAM only caching
[ https://issues.apache.org/jira/browse/TS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-119: - Fix Version/s: (was: 3.1.2) 3.2.0 > RAM only caching > > > Key: TS-119 > URL: https://issues.apache.org/jira/browse/TS-119 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: John Plevyak >Priority: Minor > Fix For: 3.2.0 > > > It would be nice if we could run with a RAM only cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-905) Improve state machine around DNS lookups and handling of URL_REMAP_FOR_OS
[ https://issues.apache.org/jira/browse/TS-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-905: - Fix Version/s: (was: 3.1.2) 3.2.0 > Improve state machine around DNS lookups and handling of URL_REMAP_FOR_OS > - > > Key: TS-905 > URL: https://issues.apache.org/jira/browse/TS-905 > Project: Traffic Server > Issue Type: Improvement > Components: DNS, HTTP >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > The code around DNS lookups in the HTTP state machine is somewhat odd. The > same state is revisited at least twice in the case of a parent proxy lookup > for example, and the internal state is not reset in between such lookups. > This caused breakage of parent proxy when we added an API to bypass origin > DNS lookup, as a very obscure side effect. > Also, there's code in there for a remapping mode URL_REMAP_FOR_OS (2), which > I believe we have crippled, and it's unclear exactly when it would be used. > We should examine this, and either fix this mode, or disable it completely. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-371) Add common process code
[ https://issues.apache.org/jira/browse/TS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-371: - Fix Version/s: (was: 3.1.2) 3.2.0 > Add common process code > --- > > Key: TS-371 > URL: https://issues.apache.org/jira/browse/TS-371 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 2.1.2 >Reporter: Mladen Turk >Assignee: Mladen Turk >Priority: Minor > Fix For: 3.2.0 > > Attachments: ink_proc.diff > > > Use the new ink_proc common API for allowing better child and daemon process > control. > The common task if "daemonizing" the process is abstracted into API making it > available for multiple > programs instead duplicating code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-199) Startup script should fail on "multiple" invocations of "start" (or "stop")
[ https://issues.apache.org/jira/browse/TS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-199: - Fix Version/s: (was: 3.1.2) 3.2.0 > Startup script should fail on "multiple" invocations of "start" (or "stop") > --- > > Key: TS-199 > URL: https://issues.apache.org/jira/browse/TS-199 > Project: Traffic Server > Issue Type: Improvement > Components: Packaging >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > Attachments: TS-199__trafficserver.in__JasonGiedymin.patch > > > If I do > # /etc/init.d/trafficserver start > # /etc/init.d/trafficserver start > I'd expect the second invocation to give an error, [NO]. Same thing with > stop, if I run stop multiple times, if there are no process(es) to stop, each > invocation ought to generate errors as well, e.g. > root@loki 507/0 # ./local/bin/trafficserver stop > Stopping : [ OK ] > Stopping : [ OK ] > Stopping : [ OK ] > root@loki 508/0 # ./local/bin/trafficserver stop > Stopping : [ NOT ] > Stopping : [ NOT ] > Stopping : [ NOT ] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-777) Increasing logbuffer size makes us "drop" log entries
[ https://issues.apache.org/jira/browse/TS-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-777: - Fix Version/s: (was: 3.1.2) 3.2.0 > Increasing logbuffer size makes us "drop" log entries > - > > Key: TS-777 > URL: https://issues.apache.org/jira/browse/TS-777 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 2.1.8 >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.2.0 > > > Setting proxy.config.log.log_buffer_size higher than somewhere around 24KB > makes us start losing log entries. This is bad, since increasing this setting > could be a way to increase performance for busy systems. I've for now set the > defaults to 16KB, which seems to be stable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-374) Potentially eliminate lock contention on HostDB
[ https://issues.apache.org/jira/browse/TS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-374: - Fix Version/s: (was: 3.1.2) 3.2.0 > Potentially eliminate lock contention on HostDB > --- > > Key: TS-374 > URL: https://issues.apache.org/jira/browse/TS-374 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > When using as a reverse proxy, when a single (or very few) HostDB entries are > under "pressure", the try-lock there could cause us to reschedule. John > suggests we look at this as a first step towards reducing latencies under > high load, by avoiding holding the lock over multiple callbacks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-57) Logging: IP's being logged in text mode when binary mode enabled for logging
[ https://issues.apache.org/jira/browse/TS-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-57: Fix Version/s: (was: 3.1.2) 3.2.0 > Logging: IP's being logged in text mode when binary mode enabled for logging > - > > Key: TS-57 > URL: https://issues.apache.org/jira/browse/TS-57 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Affects Versions: 2.0.0a > Environment: All platforms >Reporter: George Paul >Assignee: George Paul >Priority: Trivial > Fix For: 3.2.0 > > > It was reported that IP's were being logged in text mode when binary logging > was enabled. This needs to be investigated and addressed if needed. > -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-659) Reduce cross dependencies in various modules
[
https://issues.apache.org/jira/browse/TS-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-659:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Reduce cross dependencies in various modules
>
>
> Key: TS-659
> URL: https://issues.apache.org/jira/browse/TS-659
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> Right now, it's very difficult to build things (e.g. traffic_logcat) without
> including pretty much the entire code base. This is because of cross
> dependencies between various modules and libraries. So, where "logging" ought
> to be fairly self sustained, it really isn't. In an attempt to decouple this
> a little, I made a stub .cc file, which traffic_logcat and traffic_logstats
> uses. Yes this is ugly. Yes, it should be fixed (hence this bug). But it
> reduces the binary size for these binaries in the normal build from around
> 34MB to 4MB, each ...
> As a help to isolate *some* of the cross dependencies, here's the ugly stub
> code:
> {code}
> #include "libts.h"
> #include "LogObject.h"
> #if defined(solaris)
> #include
> #include
> #endif
> #include "P_Net.h"
> int fds_limit = 8000;
> UDPNetProcessor &udpNet;
> ClassAllocator udpPacketAllocator("udpPacketAllocator");
> void
> UDPConnection::Release()
> {
> ink_release_assert(false);
> }
> void
> UDPNetProcessor::FreeBandwidth(Continuation * udpConn)
> {
> ink_release_assert(false);
> }
> NetProcessor& netProcessor;
> Action *
> UnixNetProcessor::connect_re_internal(Continuation * cont, unsigned int ip,
> int port, NetVCOptions * opt)
> {
> ink_release_assert(false);
> return NULL;
> }
> #include "InkAPIInternal.h"
> ConfigUpdateCbTable *global_config_cbs = NULL;
> void
> ConfigUpdateCbTable::invoke(const char *name)
> {
> ink_release_assert(false);
> }
> const char *
> event_int_to_string(int event, int blen, char *buffer)
> {
> ink_release_assert(false);
> return NULL;
> }
> struct Machine;
> Machine *
> this_machine()
> {
> ink_release_assert(false);
> return NULL;
> }
> #include "LogConfig.h"
> void
> LogConfig::setup_collation(LogConfig * prev_config)
> {
> ink_release_assert(false);
> }
> void
> LogConfig::create_pre_defined_objects_with_filter(const
> PreDefinedFormatInfoList & pre_def_info_list, size_t num_filters,
> LogFilter ** filter, const
> char *filt_name, bool force_extension)
> {
> ink_release_assert(false);
> }
> int
> LogHost::write(LogBuffer * lb, size_t * to_disk, size_t * to_net, size_t *
> to_pipe)
> {
> ink_release_assert(false);
> return 0;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-53) remove old management code
[ https://issues.apache.org/jira/browse/TS-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-53: Fix Version/s: (was: 3.1.2) 3.2.0 > remove old management code > -- > > Key: TS-53 > URL: https://issues.apache.org/jira/browse/TS-53 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Bryan Call >Priority: Minor > Fix For: 3.2.0 > > > Remove old management code that we won't use. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-312) add option to always share keep-alive connections to the origin server
[ https://issues.apache.org/jira/browse/TS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-312: - Fix Version/s: (was: 3.1.2) 3.2.0 > add option to always share keep-alive connections to the origin server > --- > > Key: TS-312 > URL: https://issues.apache.org/jira/browse/TS-312 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Reporter: Miles Libbey >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > (was yahoo bug 1411758) > Original description > by Bryan Call (bcall) 2 years ago at 2007-08-08 13:35 > Leif and I were talking about extending the meaning of > proxy.config.http.share_server_session for reusing keep-alive connections > from the TS server and the origin server, for separate clients attached to > TS. You can read more about this in > [BUG 1162233]. The configuration options should be: > so lets add more "options" to share_server_session? E.g. > 0 - Never share/reuse connections > 1 - Share/reuse connections if max_connections is set (default) > 2 - Always try to share-reuse connections > option 1 will give the behavior we currently have and 2 will always try to > share the keep-alive connections to the > origin servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-315: - Fix Version/s: (was: 3.1.2) 3.2.0 > Add switch to disable config file generation/runtime behavior changing > -- > > Key: TS-315 > URL: https://issues.apache.org/jira/browse/TS-315 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Miles Libbey >Priority: Minor > Fix For: 3.2.0 > > > (was yahoo bug 1863676) > Original description > by Michael S. Fischer 2 years ago at 2008-04-09 09:52 > In production, in order to improve site stability, it is imperative that TS > never accidentally overwrite its own > configuration files. > For this reason, we'd like to request a switch be added to TS, preferably via > the command line, that disables all > automatic configuration file generation or other runtime behavioral changes > initiated by any form of IPC other than > 'traffic_line -x' (including the web interface, etc.) > > > Comment 1 > by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 > A very crucial request, in my opinion. If TS needs to be able to read > command-line config changes on the fly, these > changes should be stored in another config file (for example > remap.config.local instead of remap.config). We have a > patch config package that overwrites 4 of the config files under > /home/conf/ts/, and with all packages > we'd like to think that the content of these files can't change outside our > control. > > Comment 2 > by Bryan Call 2 years ago at 2008-04-09 11:02:46 > traffic_line -x doesn't modify the configuration, it reloads the > configuration files. If we want to have an option for > this it would be good to have it as an option configuration file (CONFIG > proxy.config.write_protect INT 1). > It would be an equivalent of write protecting floppies (ahh the memories)... > > > Comment 3 > by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 > I don't think it would be a good idea to have this in the configuration file, > as it would introduce a chicken/egg > problem. > > > Comment 4 > by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 > So I'm not 100% positive that this isn't just a bad interaction. Now, it's > only > triggered when trafficserver is running, but usually what ends up happening > is that we get a records.config which > looks like it's the default config that comes with the trafficserver package. > It's possible it's all one and the same issue, or we might have two issues. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-391) Cleanup file header descriptions
[ https://issues.apache.org/jira/browse/TS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-391: - Fix Version/s: (was: 3.1.2) 3.2.0 > Cleanup file header descriptions > > > Key: TS-391 > URL: https://issues.apache.org/jira/browse/TS-391 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > Most of our file headers has a Doxygen comment like > /** @file > A brief file description > We should fix this, and properly describe each file. :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-481) Missing remap support for two cases
[ https://issues.apache.org/jira/browse/TS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-481: - Fix Version/s: (was: 3.1.2) 3.2.0 > Missing remap support for two cases > --- > > Key: TS-481 > URL: https://issues.apache.org/jira/browse/TS-481 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > There are two cases where the remap processor is not used, but it should. As > of v2.1.4, the broken support was removed (broken code is worse than no > code), making two cases not use / support "remap" features. Both cases > currently call request_url_remap() which is now set to return false. The two > cases are > 1) If you configure remap mode to be URL_REMAP_FOR_OS (2). This is an > undocumented feature, I don't even know when or why you'd want to use it. The > setting in RecordsConfig.cc is proxy.config.url_remap.url_remap_mode, which > defaults to "1". > 2) If TS uses "raw" connections, I think for example when using the CONNECT > method, we will not do remap rules. This would be in a forward proxy mode, > primarily for things like HTTPS afaik. > I don't think either case are critical to get support for the remap processor > for v2.2, but please adjust the fix version if necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-656) reimplement Connection Collapsing in a smoth way
[ https://issues.apache.org/jira/browse/TS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-656: - Fix Version/s: (was: 3.1.2) 3.2.0 > reimplement Connection Collapsing in a smoth way > > > Key: TS-656 > URL: https://issues.apache.org/jira/browse/TS-656 > Project: Traffic Server > Issue Type: Improvement >Affects Versions: 2.1.6 > Environment: per discussed in IRC, we'd like to clean the current CC > codes from trunk. >Reporter: Zhao Yongming > Fix For: 3.2.0 > > > we should figure out how to implement the Connection Collapsing that not so > ugly. target for V3.1 or so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-672) cleanup Win32 references
[ https://issues.apache.org/jira/browse/TS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-672: - Fix Version/s: (was: 3.1.2) 3.2.0 > cleanup Win32 references > > > Key: TS-672 > URL: https://issues.apache.org/jira/browse/TS-672 > Project: Traffic Server > Issue Type: Improvement >Reporter: Igor Galić > Fix For: 3.2.0 > > > See: http://www.mail-archive.com/dev@trafficserver.apache.org/msg02413.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-382) socket option "cleanup" (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-382: - Fix Version/s: (was: 3.1.2) 3.2.0 > socket option "cleanup" (and bug fixes) > --- > > Key: TS-382 > URL: https://issues.apache.org/jira/browse/TS-382 > Project: Traffic Server > Issue Type: Bug > Components: Network >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > This is a bug moved from Y! Bugzilla, I'm posting the original bug > description and a few comments separately. Note that the bug description is > fairly limited, but while looking at this code, I noticed a lot of oddities > with the "socket option" support (lots of hardcoded stuff, and most of it is > not configurable). > Note that the original bug should have been fixed already in Apache TS, but > the other comments are still applicable. > From Bugzilla (posted by Leif): > We have two socket option config options in records.config: > proxy.config.net.sock_option_flag_in > proxy.config.net.sock_option_flag_out > With accept thread enabled, at least the _in option isn't honored. There are > possibly other cases in UnixNetAccept.cc > that we don't honor these flags either. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-646) Manager should be able to restart/crash w/o taking down the traffic server process.
[ https://issues.apache.org/jira/browse/TS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-646: - Fix Version/s: (was: 3.1.2) 3.2.0 > Manager should be able to restart/crash w/o taking down the traffic server > process. > --- > > Key: TS-646 > URL: https://issues.apache.org/jira/browse/TS-646 > Project: Traffic Server > Issue Type: Improvement > Components: Management >Reporter: John Plevyak > Fix For: 3.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-341) Update Contrib Scripts
[ https://issues.apache.org/jira/browse/TS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-341: - Fix Version/s: (was: 3.1.2) 3.2.0 > Update Contrib Scripts > -- > > Key: TS-341 > URL: https://issues.apache.org/jira/browse/TS-341 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 2.0.0 > Environment: EC2 >Reporter: Jason Giedymin >Assignee: Jason Giedymin >Priority: Minor > Labels: Contrib, EC2, Scripts > Fix For: 3.2.0 > > > - The EC2 images i created last month had updates to the contrib scripts > which need to be synced with the source repo. > - Need to udpate the scripts to point to the source repo -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-407) traffic_server not using proxy.config.syslog_facility
[
https://issues.apache.org/jira/browse/TS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-407:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> traffic_server not using proxy.config.syslog_facility
> -
>
> Key: TS-407
> URL: https://issues.apache.org/jira/browse/TS-407
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> We have this code in Main.cc:
> static int syslog_facility = LOG_DAEMON;
> // static void syslog_log_configure()
> //
> // Reads the syslog configuration variable
> // and sets the global integer for the
> // facility and calls open log with the
> // new facility
> //
> static void
> syslog_log_configure()
> {
> char *facility_str = NULL;
> int facility;
> TS_ReadConfigStringAlloc(facility_str, "proxy.config.syslog_facility");
> if (facility_str == NULL || (facility =
> facility_string_to_int(facility_str)) < 0) {
> syslog(LOG_WARNING, "Bad or missing syslog facility. " "Defaulting to
> LOG_DAEMON");
> } else {
> syslog_facility = facility;
> closelog();
> openlog("traffic_server", LOG_PID | LOG_NDELAY | LOG_NOWAIT, facility);
> }
> }
> But as far as I can tell, we never use syslog_facility.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-182) Make it possible to have proxy.config.proxy_name default to `hostname`
[ https://issues.apache.org/jira/browse/TS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-182: - Fix Version/s: (was: 3.1.2) 3.2.0 > Make it possible to have proxy.config.proxy_name default to `hostname` > -- > > Key: TS-182 > URL: https://issues.apache.org/jira/browse/TS-182 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > It'd be nice if we could make the records.config setting for the "proxy name" > be something like > CONFIG proxy.config.proxy_name STRING "%h" > where %h evaluates to the equivalent of `hostname`. I don't know what other % > strings could be useful, but maybe > %p - port > %d - the domain (`domainname`) > %i - the IP -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-309) Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-309: - Fix Version/s: (was: 3.1.2) 3.2.0 > Report OS Errors in Header > -- > > Key: TS-309 > URL: https://issues.apache.org/jira/browse/TS-309 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Miles Libbey > Fix For: 3.2.0 > > > (from yahoo bug 1021194) > Original description > by Ryan Troll 3 years ago at 2007-01-17 13:20 > Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 > Scott asked for a way to look at a YTS > response and differentiate between a TS error, and an Origin server error. > I *think* the general idea is that, whenever the origin server returns an > error; we return it to the client. > However, if there's a problem contacting the origin server, we should return > the appropriate HTTP response: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 > including > 500 Internal Server Error > 501 Not Implemented > 502 Bad Gateway > 503 Service Unavailable > 504 Gateway Timeout > 505 HTTP Version Not Supported > and specify what Origin Server triggered the error in the Warning header: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 > I think we could define our own warn code and use it specify the origin > server host (by name and IP): > 504 Gateway Timeout > Date: Wed, 17 Jan 2007 21:17:25 GMT > Warning: 599 l1.ycs.s1s.yahoo.com:80 "OS: us.yimg.com [66.218.71.81]" > But that's just a thought. Maybe mnot has a good suggestion -- he pointed us > towards the Warning: header, and may > know of good examples of it's use in the real world. > > > Comment 1 > by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 > There's a pretty cool feature in TS, where it embeds codes into a Via > header (if those are turned on) where someone looking at the headers can see > whether it was a cache hit, an IMS hit, etc. As it moves through the state > machine, it appends characters to the string - and in the reply you get > something like [uN l oS f pS eN] which would translate to a user issuing a > no-cache pragma, that resulted in an origin server fetch, which was served > without error. It's pretty useful, so we might want to consider enabling > this. > There's a cheat sheet at > /dev/traffic/trunk/proxy/http2/README.via > chuck -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-58) Logging: Unified logging
[ https://issues.apache.org/jira/browse/TS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-58: Fix Version/s: (was: 3.1.2) 3.2.0 > Logging: Unified logging > > > Key: TS-58 > URL: https://issues.apache.org/jira/browse/TS-58 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.0a > Environment: All platforms >Reporter: George Paul >Priority: Minor > Fix For: 3.2.0 > > > There is a request to unify the logging in Traffic Server system. This would > entail modifying the Diagnostic logging system to use the internal > transaction logging system which uses non-locking buffers and a separate > thread. The changes would affect both the Traffic Server and Traffic Manager > which use the Diagnostic logging for event logging similar to syslog(). > -George -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-628) Add better config option for forward proxying
[ https://issues.apache.org/jira/browse/TS-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-628: - Fix Version/s: (was: 3.1.2) 3.2.0 > Add better config option for forward proxying > - > > Key: TS-628 > URL: https://issues.apache.org/jira/browse/TS-628 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration > Environment: All >Reporter: Marcus Clyne >Priority: Trivial > Fix For: 3.2.0 > > > Hi, > When setting up forward proxy on TS, currently it is required to set > proxy.config.url_remap.remap_required INT 0 > This is a bit obscure, and makes it more difficult for people who only work > with TS on an occasional basis to guess at the config option. > I think having an option like > proxy.config.forward_proxy.enable > or > proxy.config.http.forward.enable (so it's similar to > proxy.config.http.forward.proxy_auth_to_parent) > would be better. > It might be a good idea (at least for a period) to have both options, so as > not to break existing configurations. > If it is decided not to change the config option, as a minimum, it would be > nice to have a comment in the configuration file saying something like 'this > needs to be set to 0 to enable forward proxying'. This would allow for > people to search the config file for the word 'forward'. > Cheers, > Marcus. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-563) Incorrectly returned 0 status code from startup script even when TS fails to start
[ https://issues.apache.org/jira/browse/TS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-563: - Fix Version/s: (was: 3.1.2) 3.2.0 > Incorrectly returned 0 status code from startup script even when TS fails to > start > -- > > Key: TS-563 > URL: https://issues.apache.org/jira/browse/TS-563 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 2.1.5 > Environment: Linux >Reporter: Marcus Clyne >Priority: Trivial > Fix For: 3.2.0 > > > When using proxy.config.log2 values in records.config rather than the new > proxy.config.log values, TS fails to start (server/manager/cop), but a return > code of 0 is returned rather than 1 or something more meaningful. > I have also noticed instances when config errors have prevented server from > starting, even though manager and cop do. It would probably make sense to > have a non-zero error code for these two. > Perhaps it might be useful to have different return codes for whether > cop/manager/server start or not (e.g. 1=server not started, 2=manager not > started, 3=cop not started? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-203) config files ownership
[ https://issues.apache.org/jira/browse/TS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-203: - Fix Version/s: (was: 3.1.2) 3.2.0 > config files ownership > -- > > Key: TS-203 > URL: https://issues.apache.org/jira/browse/TS-203 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > It's semi-odd that the admin user (nobody) is also the user as to which > traffic_server process changes it's euid to. This means that the > traffic_server process has write permissions on the config files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-310) modifying global_user_agent_header requires restart
[ https://issues.apache.org/jira/browse/TS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-310: - Fix Version/s: (was: 3.1.2) 3.2.0 > modifying global_user_agent_header requires restart > --- > > Key: TS-310 > URL: https://issues.apache.org/jira/browse/TS-310 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Miles Libbey >Priority: Minor > Fix For: 3.2.0 > > > (was y bug 1389544) > Original description > by Leif Hedstrom2 years ago at 2007-07-26 16:38 > I don't know why, or if it's intentional, but modifying the config for > proxy.config.http.global_user_agent_header > requires a server restart. This is obviously not a huge problem, but > inconsistent and confusing. I can't think of any > reasons why we shouldn't support "dynamically" rereading this particular > configuration. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-766) Authenticate access to cluster command port
[ https://issues.apache.org/jira/browse/TS-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-766: - Fix Version/s: (was: 3.1.2) 3.2.0 > Authenticate access to cluster command port > --- > > Key: TS-766 > URL: https://issues.apache.org/jira/browse/TS-766 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Network >Affects Versions: 2.1.8 >Reporter: Arno Toell > Labels: security > Fix For: 3.2.0 > > > Similar to TS-765, the cluster RPC interface should not be reachable by > everyone. Instead some kind of peer authentication should apply. When > clustering is enabled, please authenticate and/or restrict access to the RPC > interface in a way only trusted peers are allowed to control the server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-305) sigTERM should cause a user-friendly shutdown
[ https://issues.apache.org/jira/browse/TS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-305: - Fix Version/s: (was: 3.1.2) 3.2.0 > sigTERM should cause a user-friendly shutdown > - > > Key: TS-305 > URL: https://issues.apache.org/jira/browse/TS-305 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Miles Libbey >Priority: Minor > Fix For: 3.2.0 > > > (from yahoo bug 848837) > Original description > by Scott Manjourides 3 years ago at 2006-10-16 15:48 > On Monday 16 October 2006 03:01 pm, Ryan Troll wrote: > > Open a RFE asking to have sigTERM cause a user-friendly > > shutdown? Something like: > > > > - immediately set all KeepAlive timeout values to 5 seconds > > > > :: Optional, but could make shutdown faster than leaving at > > :: whatever the property specified. > > > > - no longer accept new connections > > - process exits when all existing connections close > > > > > > -R > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-149) Split ram and disk cache hit response times into separate metrics
[ https://issues.apache.org/jira/browse/TS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-149: - Fix Version/s: (was: 3.1.2) 3.2.0 > Split ram and disk cache hit response times into separate metrics > - > > Key: TS-149 > URL: https://issues.apache.org/jira/browse/TS-149 > Project: Traffic Server > Issue Type: New Feature > Components: Cache >Reporter: Anirban >Priority: Minor > Fix For: 3.2.0 > > > Split ram and disk cache hit response times into separate metrics > Original description > by Stephen Bisordi from Yahoo > It appears that the response time for ram cache hits and disk cache hits is > captured as a single metric > (transaction_totaltime.hit_fresh). Would it be possible to split this into > two separate metrics, or to add a ram cache > hit result code to the log to differentiate between ram and disk hits > (similar to Squid's TCP_MEM_HIT)? > This change would allow for quicker troubleshooting of certain issues such as > poor disk performance. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-698) LogFilter should support an actual IP type and matching rules
[
https://issues.apache.org/jira/browse/TS-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-698:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> LogFilter should support an actual IP type and matching rules
> -
>
> Key: TS-698
> URL: https://issues.apache.org/jira/browse/TS-698
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Affects Versions: 2.1.6
> Environment: N/A
>Reporter: Eric Connell
>Priority: Minor
> Fix For: 3.2.0
>
>
> The LogFilter configuration in logs_xml.config should support a native IPv4
> and IPv6 filtering. For example, it would be handy to be able to filter out
> log lines from a specific server or netblock. For example, the following
> config would reject log lines for all hosts in the 10/8 network:
> {code}
>
>
>
>
>
>
>
>
> "/>
>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-54) UnixNet cleanup, encapsulation of event subsystem
[ https://issues.apache.org/jira/browse/TS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-54: Fix Version/s: (was: 3.1.2) 3.2.0 > UnixNet cleanup, encapsulation of event subsystem > - > > Key: TS-54 > URL: https://issues.apache.org/jira/browse/TS-54 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup > Environment: all unixesque >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 3.2.0 > > Attachments: proposed-jp-v1-List.h, ts-List-net-cleanup-jp-v2.patch, > ts-List_and_net-cleanup-jp-v1.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The UnixNet subsystem was modified for epoll, but lots of the old data > structures, data members and code > remain for the old "bucket" approach. > The epoll code should also be encapsulated to simplify support for other > platforms and a possible move > to an event library. > The current code is complicated by limitations in Queue which require > specifying the link field for every > use, but which can be fixed by in the template. > Finally, the current code does an unnecessary allocation for the epoll struct > which should be part of the NetVConnection etc. > and it takes a lock for the enable_queue which can be avoided by using the > non-locking AtomicSSL. > This work is also good preparation for evaluating libev or libevent as it > will reduce the amount of code which > will have to be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-795) Clean up definitions and usage of buffer size indexes vs buffer sizes
[
https://issues.apache.org/jira/browse/TS-795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-795:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Clean up definitions and usage of buffer size indexes vs buffer sizes
> -
>
> Key: TS-795
> URL: https://issues.apache.org/jira/browse/TS-795
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Leif Hedstrom
> Fix For: 3.2.0
>
>
> Right now, we have a set of defines, and APIs, which can take either a
> "index" to a size (used e.g. for an allocator index), or a real size. Both of
> these are currently int64_t in all APIs and member variables, and in the
> implementations, the usage are sometimes overloaded (i.e. we do "size"
> calculations on top of the indexes, making for real confusing code).
> There's also a lack of proper identification of what is an "size index" type
> (or parameter), and what is a "size". This makes for risky code.
> I think we should clean up all the implementations and APIs, as follow
> 1) Make proper names of all APIs and macros, clearly indicating if it's
> working on a size index or a size.
> 2) Keep only the size types, parameters and macros using int64_t. Do not
> overload "real" size over the size indexes.
> 3) We either make the size indexes an "int" (or even a short), or perhaps
> even better an enum (like below). All APIs, parameters, and member variables
> that refer to such size indexes would use this appropriate type.
> {code}
> enum BufferSizeIndex {
> BUFFER_SIZE_INDEX_128 = 0,
> BUFFER_SIZE_INDEX_256, /* 1 */
> BUFFER_SIZE_INDEX_512, /* 2 */
> BUFFER_SIZE_INDEX_1K,/* 3 */
> BUFFER_SIZE_INDEX_2K,/* 4 */
> BUFFER_SIZE_INDEX_4K,/* 5 */
> BUFFER_SIZE_INDEX_8K,/* 6 */
> BUFFER_SIZE_INDEX_16K, /* 7 */
> BUFFER_SIZE_INDEX_32K, /* 8 */
> BUFFER_SIZE_INDEX_64K, /* 9 */
> BUFFER_SIZE_INDEX_128K, /* 10 */
> BUFFER_SIZE_INDEX_256K, /* 11 */
> BUFFER_SIZE_INDEX_512K, /* 12 */
> BUFFER_SIZE_INDEX_1M,/* 13 */
> BUFFER_SIZE_INDEX_2M,/* 14 */
> /* These have special semantics */
> BUFFER_SIZE_NOT_ALLOCATED,
> };
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-274) UA side SSL support in forward proxy
[
https://issues.apache.org/jira/browse/TS-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-274:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> UA side SSL support in forward proxy
>
>
> Key: TS-274
> URL: https://issues.apache.org/jira/browse/TS-274
> Project: Traffic Server
> Issue Type: New Feature
> Components: SSL
>Affects Versions: 2.1.0, 2.0.0a
> Environment: Debian, Linux 2.6.18 32-bit
>Reporter: Marcus Clyne
> Labels: ssl
> Fix For: 3.2.0
>
>
> Using self-signed SSL certificates, which are in the correct paths under
> $prefix, and giving no startup errors, I get the following error when making
> a request through the proxy :
> Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
> SSL_ServerHandShake.
> Mar 24 14:35:09 www traffic_server[27926]: {1146895248} ERROR:
> SSL::5:error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy
> request:s23_srvr.c:384:
> Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR: SSL ERROR:
> SSL_ServerHandShake.
> Mar 24 14:36:47 www traffic_server[27926]: {1146895248} ERROR:
> SSL::5:error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http
> request:s23_srvr.c:379:
> The first of these two was from using Proxifier (Windows software) to connect
> to the server, the second is from using `curl -k -x $ip:443
> http://google.com/`.
> The issue appears on the latest trunk version and the 2.0.x branch as of
> today when used in forward proxy mode.
> I have not personally tested in reverse proxy mode, but zwoop (Freenode IRC
> name) tested in reverse proxy mode, and reverse proxy mode worked only in the
> 2.0.x but not trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-658) HTTP SM holds the cache write lock for too long
[ https://issues.apache.org/jira/browse/TS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-658: - Fix Version/s: (was: 3.1.2) 3.2.0 > HTTP SM holds the cache write lock for too long > --- > > Key: TS-658 > URL: https://issues.apache.org/jira/browse/TS-658 > Project: Traffic Server > Issue Type: Bug >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > It seems we open the cache for write very early on in the HTTP SM, which can > have very bad effect on performance if the object is not cacheable. It's not > totally clear as to why this is done this way, but we should examine this for > v3.1, and try to minimize how long we hold the lock. It's possible this is > related to read_while_writer, but then it should be modified IMO. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-548) What is Initialize.cc /.h ??
[ https://issues.apache.org/jira/browse/TS-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-548: - Fix Version/s: (was: 3.1.2) 3.2.0 > What is Initialize.cc /.h ?? > > > Key: TS-548 > URL: https://issues.apache.org/jira/browse/TS-548 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > This code isn't built, nor used, as far as I can tell, and seems "duplicated" > from what is available and used elsewhere. What is it? Should it be removed? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-785) Building outside of the tree does not work
[
https://issues.apache.org/jira/browse/TS-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-785:
-
Fix Version/s: (was: 3.1.2)
3.2.0
> Building outside of the tree does not work
> --
>
> Key: TS-785
> URL: https://issues.apache.org/jira/browse/TS-785
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Igor Galić
> Labels: build
> Fix For: 3.2.0
>
>
> {noformat}
> igalic@bawnb976 ~/Projects/asf/ats-build % ../trafficserver/configure
> --prefix=/opt/dev
>
> ...
> igalic@bawnb976 ~/Projects/asf/ats-build % make
> Making all in proxy/api/ts
> make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts'
> Making all in iocore
> make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/iocore'
> Making all in eventsystem
> make[2]: Entering directory
> `/home/igalic/Projects/asf/ats-build/iocore/eventsystem'
> g++ -DHAVE_CONFIG_H -I. -I../../../trafficserver/iocore/eventsystem
> -I../../lib/ts -I../../../trafficserver/lib/records -D_LARGEFILE64_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux
> -I/usr/include/tcl8.4 -mtune=native -march=native -Wall -O3 -march=i586 -g
> -pipe -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
> -Wno-invalid-offsetof -MT EventSystem.o -MD -MP -MF .deps/EventSystem.Tpo -c
> -o EventSystem.o ../../../trafficserver/iocore/eventsystem/EventSystem.cc
> In file included from
> ../../../trafficserver/iocore/eventsystem/EventSystem.cc:31:0:
> ../../../trafficserver/iocore/eventsystem/P_EventSystem.h:39:19: fatal error:
> libts.h: No such file or directory
> compilation terminated.
> make[2]: *** [EventSystem.o] Error 1
> make[2]: Leaving directory
> `/home/igalic/Projects/asf/ats-build/iocore/eventsystem'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/iocore'
> make: *** [all-recursive] Error 1
> 2 igalic@bawnb976 ~/Projects/asf/ats-build %
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-219) Daemon should not rely on init script exclusively for pid/lock removal.
[ https://issues.apache.org/jira/browse/TS-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-219: - Fix Version/s: (was: 3.1.2) 3.2.0 > Daemon should not rely on init script exclusively for pid/lock removal. > --- > > Key: TS-219 > URL: https://issues.apache.org/jira/browse/TS-219 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 2.0.0a >Reporter: Jason Giedymin >Priority: Minor > Labels: daemon, init, linux, lock, pid, script > Fix For: 3.2.0 > > > Having the ts daemon remove it's PID will be useful. > Init script can then do 'cleanup' if necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-641) WebUI: Kill it with fire.
[ https://issues.apache.org/jira/browse/TS-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-641: - Fix Version/s: (was: 3.1.2) 3.2.0 > WebUI: Kill it with fire. > - > > Key: TS-641 > URL: https://issues.apache.org/jira/browse/TS-641 > Project: Traffic Server > Issue Type: Improvement > Components: Web UI >Reporter: Igor Galić >Assignee: Igor Galić > Fix For: 3.2.0 > > Original Estimate: 14m > Remaining Estimate: 14m > > Get rid of proxy/mgmt/html2 > Get rid of all code in proxy/mgmt/web2 that is not used > Merge used code into proxy/mgmt/utils/WebMgmtUtils.* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-484) INKHttpTxnSetRespCacheableSet() vs INKHttpTxnServerRespNoStore()
[ https://issues.apache.org/jira/browse/TS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-484: - Fix Version/s: (was: 3.1.2) 3.2.0 > INKHttpTxnSetRespCacheableSet() vs INKHttpTxnServerRespNoStore() > > > Key: TS-484 > URL: https://issues.apache.org/jira/browse/TS-484 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom > Fix For: 3.2.0 > > > it seems that the logic around the new API INKHttpTxnSetRespCacheableSet() is > very similar to the old, existing INKHttpTxnServerRespNoStore(). Would it be > possible to "merge" the new API logic into the existing one (without changing > the old API) ? This would be a great thing to fix before we finalize v2.2, > to avoid breaking / adding more APIs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-153) "Dynamic" keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-153: - Fix Version/s: (was: 3.1.2) 3.2.0 > "Dynamic" keep-alive timeouts > - > > Key: TS-153 > URL: https://issues.apache.org/jira/browse/TS-153 > Project: Traffic Server > Issue Type: New Feature > Components: Core >Reporter: Leif Hedstrom >Priority: Minor > Fix For: 3.2.0 > > > (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally > posted by Leif Hedstrom on 2008-03-19): > Currently you have to set static keep-alive idle timeouts in TS, e.g. >CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8 >CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30 > even with epoll() in 1.17.x, this is difficult to configure, and put an > appropriate timeout. The key here is that the > settings above need to assure that you stay below the max configured number > of connections, e.g.: > CONFIG proxy.config.net.connections_throttle INT 75000 > I'm suggesting that we add one (or two) new configuration options, and > appropriate TS code support, to instead of > specifying timeouts, we specify connection limits for idle KA connections. > For example: > CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 5 > CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000 > (one still has to be careful to leave head-room for active connections here, > in the example above, 2 connections > could be active, which is a lot of traffic). > These would override the idle timeouts, so one could use the max_idle > connections for incoming (client) connections, > and the idle timeouts for outgoing (origin) connections for instance. > The benefit here is that it makes configuration not only easier, but also a > lot safer for many applications. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-667) Ability to keep traffic server from initializing the wrong disks when using RAW disk mode.
[ https://issues.apache.org/jira/browse/TS-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-667: - Fix Version/s: (was: 3.1.2) 3.2.0 > Ability to keep traffic server from initializing the wrong disks when using > RAW disk mode. > -- > > Key: TS-667 > URL: https://issues.apache.org/jira/browse/TS-667 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Configuration >Reporter: David Robinson >Priority: Minor > Labels: features > Fix For: 3.2.0 > > > When disk devices are configured in storage.config for RAW mode they are > automatically initialized when traffic server first starts up. If disk device > names change later due to adding/removing disks or kernel changes > trafficserver will overwrite disks that the user may not want to be cache > disks. This leads to data loss on the affected disks. > Maybe a feature could be added similar to squid's -z where cache disks must > be explicitly initialized before they can be used. Or a configuration > variable that changes trafficserver's initialization behavior. > (6:49:06 PM) zwoop: so, maybe have a few settings for the config > (6:49:06 PM) zwoop: 0 - Let it reinitialize cache as it likes > (6:49:06 PM) zwoop: 1 - Only initialize cache explicitly > (6:49:06 PM) zwoop: 2 - Only initialize cache explicitly, and refuse to start > up if we detect a cache disk with bad header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-854) backdoor port 8084 should be bind on 127.0.0.1?
[
https://issues.apache.org/jira/browse/TS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-854.
--
Resolution: Invalid
Fix Version/s: (was: 3.1.2)
Resolving this issue, please reopen if it's still an issue.
> backdoor port 8084 should be bind on 127.0.0.1?
> ---
>
> Key: TS-854
> URL: https://issues.apache.org/jira/browse/TS-854
> Project: Traffic Server
> Issue Type: Improvement
> Components: Management
>Affects Versions: 3.1.0
>Reporter: Zhao Yongming
>Priority: Minor
>
> 8084 is now just for cop do health checking on server, it should not open to
> the wild Internet by default.
> {codes}
> zym6400 trafficserver # netstat -lantp | grep 8084
> tcp0 0 127.0.0.1:8084 0.0.0.0:* LISTEN
> 22919/traffic_serve
> tcp0 0 127.0.0.1:8084 127.0.0.1:53968 TIME_WAIT
> -
> tcp0 0 127.0.0.1:8084 127.0.0.1:34967 TIME_WAIT
> -
> tcp0 0 127.0.0.1:8084 127.0.0.1:56713 TIME_WAIT
> -
> tcp0 0 127.0.0.1:8084 127.0.0.1:58371 TIME_WAIT
> -
> tcp0 0 127.0.0.1:8084 127.0.0.1:37322 TIME_WAIT
> -
> tcp0 0 127.0.0.1:8084 127.0.0.1:39422 TIME_WAIT
> -
> {codes}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-518) Close UA connection early if the origin sent Connection close:, there's a bad Content-Length header, and the UA connection has Keep-Alive.
[ https://issues.apache.org/jira/browse/TS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-518: - Fix Version/s: (was: 3.1.1) 3.3.0 > Close UA connection early if the origin sent Connection close:, there's a bad > Content-Length header, and the UA connection has Keep-Alive. > -- > > Key: TS-518 > URL: https://issues.apache.org/jira/browse/TS-518 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > In a very special case, we could improve the user experience by forcefully > closing the connection early. The case is > 1) The origin server sends a Content-Length: header that is wrong, where the > CL: value exceeds the actually body size. > 2) The origin server either sends a Connection: close, or it uses HTTP/1.0 > without keep-alive. > 3) The client (and TS) uses Keep-Alive to the UA. > In this case, we can end up stalling the UA until either the UA or the TS > connection times out. It might make sense to prematurely disconnect the > client when this case is detected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-846) Remap processor options could be integrated to a single option
[ https://issues.apache.org/jira/browse/TS-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-846: - Fix Version/s: (was: 3.1.1) 3.3.0 > Remap processor options could be integrated to a single option > -- > > Key: TS-846 > URL: https://issues.apache.org/jira/browse/TS-846 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Affects Versions: 3.0.0 >Reporter: Eric Balsa >Assignee: Eric Balsa >Priority: Minor > Fix For: 3.3.0 > > Original Estimate: 2h > Remaining Estimate: 2h > > TS_ReadConfigInteger(use_separate_thread, > "proxy.config.remap.use_remap_processor"); > and > TS_ReadConfigInteger(num_remap_threads, > "proxy.config.remap.num_remap_threads"); > should be changed to a single config > TS_ReadConfigInteger(num_remap_threads, > "proxy.config.remap.num_remap_threads"); > whereby a setting of "0" would indicate not to use a separate thread(s) for > remapping. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-468) We should respond with a 417 if we cannot meet an expectation
[ https://issues.apache.org/jira/browse/TS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-468: - Fix Version/s: (was: 3.1.1) 3.3.0 > We should respond with a 417 if we cannot meet an expectation > - > > Key: TS-468 > URL: https://issues.apache.org/jira/browse/TS-468 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > If the client sends an Expect: header that we cannot meet, we should return a > 417 error. E.g. > Expect: expect=params > since we can't meet this expectation, we should return a 417, but instead we > forward this to the origin, and return with whatever it responds with. > (Originally found using Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-235) cleanup libinktomi++
[ https://issues.apache.org/jira/browse/TS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-235: - Fix Version/s: (was: 3.1.1) 3.3.0 > cleanup libinktomi++ > > > Key: TS-235 > URL: https://issues.apache.org/jira/browse/TS-235 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.6 >Reporter: John Plevyak >Assignee: John Plevyak >Priority: Critical > Fix For: 3.3.0 > > Attachments: rename-inkmd5.sh > > > libinktomi++ is a bit of a mess... e.g. ink_port.h Portability.h > Compatability.h, yes you guessed > it, they all do very similar things. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[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: 3.1.1) 3.3.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.3.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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-357) Compiling with -Wconversion generates a lot of errors
[ https://issues.apache.org/jira/browse/TS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-357: - Fix Version/s: (was: 3.1.1) 3.3.0 > Compiling with -Wconversion generates a lot of errors > - > > Key: TS-357 > URL: https://issues.apache.org/jira/browse/TS-357 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Affects Versions: 2.1.0 >Reporter: Bryan Call > Fix For: 3.3.0 > > > After adding -Wconversion to CFLAGS and CXXFLAGS I got 11k errors: > [bcall@snowball traffic.git]$ gmake -k 2> /dev/stdout | grep -c ' error: ' > 11432 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-469) A PUT request should invalidate a previously cached object with the same URI
[ https://issues.apache.org/jira/browse/TS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-469: - Fix Version/s: (was: 3.1.1) 3.3.0 > A PUT request should invalidate a previously cached object with the same URI > > > Key: TS-469 > URL: https://issues.apache.org/jira/browse/TS-469 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.6 >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > If the client first fetches an object with GET, and TS caches it, a > subsequent PUT request for the same URL should invalidate the cached object. > (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 clent is broken
[ https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-464: - Fix Version/s: (was: 3.1.1) 3.3.0 > Chunked response with bad Content-Length header to HTTP/1.0 clent is broken > --- > > Key: TS-464 > URL: https://issues.apache.org/jira/browse/TS-464 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > A client sends an HTTP/1.0 request through ATS, which gets proxied with > HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) > returns with both > Content-Length: 10 > Transfer-Encoding: chunked > and a chunked body which is > 10 bytes long. In this case, ATS should still > respond with an HTTP/1.0 response, undoing the chunking, and return with an > appropriate CL: header. We do everything, except set the correct > Content-Length header, we simply return the erroneous CL header that the > Origin provided. This is not allowed in the RFC. > (Originally discovered using Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-467) Proxy shold not forward request headers that matches a Connection token
[ https://issues.apache.org/jira/browse/TS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-467: - Fix Version/s: (was: 3.1.1) 3.3.0 > Proxy shold not forward request headers that matches a Connection token > --- > > Key: TS-467 > URL: https://issues.apache.org/jira/browse/TS-467 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > > If a client sends a request like > X-foobar: fum > Connection: ,,X-foobar,, > the proxy (Traffic Server) MUST remove the header X-foobar before forwarding > the request. From the RFC: > HTTP/1.1 proxies MUST parse the Connection header field before a >message is forwarded and, for each connection-token in this field, >remove any header field(s) from the message with the same name as the >connection-token. > and > A system receiving an HTTP/1.0 (or lower-version) message that >includes a Connection header MUST, for each connection-token in this >field, remove and ignore any header field(s) from the message with >the same name as the connection-token. > (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-608) Is HttpSessionManager::purge_keepalives() too aggressive?
[ https://issues.apache.org/jira/browse/TS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-608: - Fix Version/s: (was: 3.1.1) 3.3.0 > Is HttpSessionManager::purge_keepalives() too aggressive? > -- > > Key: TS-608 > URL: https://issues.apache.org/jira/browse/TS-608 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 3.3.0 > > Attachments: TS-608.patch > > > It seems that if we trigger the "max server connections", we call this purge > function in the session manager, which will close all currently open > keep-alive connections. This seems very aggressive, why not limit it to say > only removing 10% of each "bucket" or some such? Also, how does this work > together with per-origin limits? Ideally, if the per-origin limits are in > place, we would only purge sessions that are for the IP we wish to connect to > ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-967) Traffic Server unconditionally sets compiler optimizing flags (with patch)
[
https://issues.apache.org/jira/browse/TS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-967:
--
Backport to Version: (was: 3.0.2)
Fix Version/s: 3.0.2
> Traffic Server unconditionally sets compiler optimizing flags (with patch)
> --
>
> Key: TS-967
> URL: https://issues.apache.org/jira/browse/TS-967
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: sometime, 3.0.1
>Reporter: Arno Toell
>Assignee: Igor Galić
> Fix For: 3.1.1, 3.0.2
>
> Attachments: dont-unconditionally-put-in-oflags.patch
>
>
> Currently, Traffic Server unconditionally sets compiler optinizing flags,
> e.g. _-O3_ and ignores any setting the user might have given at build time
> through, e.g. {{CFLAGS}}.
> The attached patch against the current trunk checks the environment for -O
> flags in {{C(XX)FLAGS}} and only sets them, if the user did not define any.
> Note: I didn't test it on Solaris.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-969) make check failing on Debian Sid and Solaris
[ https://issues.apache.org/jira/browse/TS-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-969: -- Backport to Version: (was: 3.0.2) Fix Version/s: 3.0.2 > make check failing on Debian Sid and Solaris > > > Key: TS-969 > URL: https://issues.apache.org/jira/browse/TS-969 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Igor Galić >Assignee: Igor Galić > Fix For: 3.1.1, 3.0.2 > > > This has been fixed in trunk: > http://svn.apache.org/viewvc?rev=1171365&view=rev > but it still affects trunk, please backport this! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-974) TS should have a mode to hold partial objects in cache
TS should have a mode to hold partial objects in cache -- Key: TS-974 URL: https://issues.apache.org/jira/browse/TS-974 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.0.1 Reporter: William Bardwell For ATS to do an excelent job caching large files like video it would need to be able to hold partial objects for a large file. This could be done in a plugin or in the core. This would need to be integrated with the Range handling code to serve requests out of the partial objects and to get more parts of a file to satisfy a Range request. An intermediate step (also do-able in the core or in a plugin) would be to have some settings to let the Range handling code be able to trigger a full file download either asynchronously when a Range response indicates that the file isn't larger than some threshold, or synchronously when a Range request could reasonably be answered quickly from a full request. (Right now Range requests are tunneled if there is not full cached content as far as I can tell.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-961) Extend TS API to support TSNetAccept with inbound transparency
[ https://issues.apache.org/jira/browse/TS-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-961: Assignee: Alan M. Carroll > Extend TS API to support TSNetAccept with inbound transparency > -- > > Key: TS-961 > URL: https://issues.apache.org/jira/browse/TS-961 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Yossi Gottlieb >Assignee: Alan M. Carroll >Priority: Minor > Fix For: 3.1.1 > > Attachments: api_transparency.diff > > > This is required for protocol plugins to use this capability. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-821) memcached_remap plugin
[ https://issues.apache.org/jira/browse/TS-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-821: - Fix Version/s: (was: 3.1.1) sometime Moving this out for now, unless someone wish to review / land it. Since it's a plugin, it's not really dependant on a release anyways. > memcached_remap plugin > -- > > Key: TS-821 > URL: https://issues.apache.org/jira/browse/TS-821 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins > Environment: Fedora 15 >Reporter: Opensource AT Navya Prabha >Assignee: Eric Balsa >Priority: Minor > Fix For: sometime > > Attachments: memcached_remap.tar.bz2 > > > to make ASF own memcached_remap plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-837) ATS fails to compile with gcc 4.6.1 with --enable-debug
[
https://issues.apache.org/jira/browse/TS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-837:
Assignee: Igor Galić
Figure this one out, #1 (or, move to some later release :).
Danke viel mal.
> ATS fails to compile with gcc 4.6.1 with --enable-debug
> ---
>
> Key: TS-837
> URL: https://issues.apache.org/jira/browse/TS-837
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 3.1.0, 3.0.0
> Environment: Linux, Debian, Amd64 + GCC 4.6.1
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 3.1.1
>
> Attachments: proxything.diff
>
>
> {noformat}
> In file included from ../../proxy/ControlMatcher.h:104:0,
> from ../../proxy/ParentSelection.h:37,
> from P_Socks.h:30,
> from P_Net.h:106,
> from Connection.cc:34:
> ../../proxy/hdrs/HTTP.h: In member function 'INK_MD5
> HTTPInfo::object_key_get()':
> ../../proxy/hdrs/HTTP.h:1375:24: error: dereferencing type-punned pointer
> will break strict-aliasing rules [-Werror=strict-aliasing]
> ../../proxy/hdrs/HTTP.h: In member function 'int64_t
> HTTPInfo::object_size_get()':
> ../../proxy/hdrs/HTTP.h:1405:24: error: dereferencing type-punned pointer
> will break strict-aliasing rules [-Werror=strict-aliasing]
> ../../proxy/hdrs/HTTP.h: In member function 'void
> HTTPInfo::object_size_set(int64_t)':
> ../../proxy/hdrs/HTTP.h:1422:51: error: dereferencing type-punned pointer
> will break strict-aliasing rules [-Werror=strict-aliasing]
> cc1plus: all warnings being treated as errors
> *** [Connection.o] Error 1
> make[2]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore/net'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore'
> make: *** [all-recursive] Error 1
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-961) Extend TS API to support TSNetAccept with inbound transparency
[ https://issues.apache.org/jira/browse/TS-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120441#comment-13120441 ] Leif Hedstrom commented on TS-961: -- Hmmm, this is an "interesting" problem, I'm not sure we can break the API / ABI like this in the middle of a 3.x release cycle. Two options I think 1) Say "wtf" and just break it (which is kinda evil) 2) Make a new API (which is evil in other ways ...) I'm personally leaning towards #2 honestly. Thoughts? > Extend TS API to support TSNetAccept with inbound transparency > -- > > Key: TS-961 > URL: https://issues.apache.org/jira/browse/TS-961 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Yossi Gottlieb >Priority: Minor > Fix For: 3.1.1 > > Attachments: api_transparency.diff > > > This is required for protocol plugins to use this capability. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-967) Traffic Server unconditionally sets compiler optimizing flags (with patch)
[
https://issues.apache.org/jira/browse/TS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120435#comment-13120435
]
Leif Hedstrom commented on TS-967:
--
Would you mind submitting a diff against current trunk? The one here fails on
most chunks.
> Traffic Server unconditionally sets compiler optimizing flags (with patch)
> --
>
> Key: TS-967
> URL: https://issues.apache.org/jira/browse/TS-967
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: sometime, 3.0.1
>Reporter: Arno Toell
>Assignee: Igor Galić
> Fix For: 3.1.1
>
> Attachments: dont-unconditionally-put-in-oflags.patch
>
>
> Currently, Traffic Server unconditionally sets compiler optinizing flags,
> e.g. _-O3_ and ignores any setting the user might have given at build time
> through, e.g. {{CFLAGS}}.
> The attached patch against the current trunk checks the environment for -O
> flags in {{C(XX)FLAGS}} and only sets them, if the user did not define any.
> Note: I didn't test it on Solaris.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
