[jira] [Updated] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1035:
--

Fix Version/s: 3.1.2

 EventProcessor::spawn_thread doesn't check that there is enough event threads 
 and segfaults
 ---

 Key: TS-1035
 URL: https://issues.apache.org/jira/browse/TS-1035
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.1
Reporter: Brian Geffon
 Fix For: 3.1.2

 Attachments: LargeNumberOfPorts.patch, UnixEventProcessor.patch


 The easiest way to see this bug is to use several hundred ports with accept 
 threads turned on. The bug exists because in I_EventProcessor.h there is a 
 hard coded limit of 512 event threads and there is no check in spawn_thread 
 that you haven't exceeded that limit so it will result in a segfault if 
 you're creating too many threads. From what I can tell the best solution is 
 an assertion that you haven't exceeded MAX_EVENT_THREADS.
 Patch is included.

--
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-1040) PATCH: teach TSHostLookup to use const

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1040:
--

Fix Version/s: 3.1.2

 PATCH: teach TSHostLookup to use const
 --

 Key: TS-1040
 URL: https://issues.apache.org/jira/browse/TS-1040
 Project: Traffic Server
  Issue Type: Improvement
  Components: DNS
Reporter: James Peach
Priority: Minor
 Fix For: 3.1.2

 Attachments: 
 0002-TSHostLookup-should-take-const-hostname-argument.patch


 This patch improves the TSHostLookup() API by specifying it's hostname 
 argument as const. This reduces the number of casts required of plugin 
 authors.
 The new prototype is:
 tsapi TSAction TSHostLookup(TSCont contp, const char* hostname, size_t 
 namelen)

--
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-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1041:
--

Fix Version/s: 3.1.2

 PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
 --

 Key: TS-1041
 URL: https://issues.apache.org/jira/browse/TS-1041
 Project: Traffic Server
  Issue Type: Improvement
  Components: DNS
 Environment: Mac OS X 10.7
Reporter: James Peach
Priority: Minor
 Fix For: 3.1.2

 Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch


 The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's 
 sa_len field populated correctly. This patch guarantees to populate it to the 
 correct value so that plugin authors can rely on that field when copying the 
 TSHostLookupResultAddrGet() result.

--
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-1045) PATCH: add new TSFetchHdrGet API

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1045:
--

Attachment: TS-1045-formatting.diff

Suggested changes for formatting, and making the functions more like the other 
similar APIs.

Maybe this won't be necessary at all, but jpeach will let us know what will be 
the right solution for these APIs.

 PATCH: add new TSFetchHdrGet API
 

 Key: TS-1045
 URL: https://issues.apache.org/jira/browse/TS-1045
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP
Reporter: James Peach
Assignee: Leif Hedstrom
Priority: Minor
 Fix For: 3.1.2

 Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch, 
 TS-1045-formatting.diff


 TSFetchUrl does not provide any way to get the headers from the result. This 
 patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() 
 and returns the headers.

--
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-1049) TS hangs (dead lock) on HTTPS POST requests

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1049:
--

Fix Version/s: 3.1.2

 TS hangs (dead lock) on HTTPS POST requests
 ---

 Key: TS-1049
 URL: https://issues.apache.org/jira/browse/TS-1049
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, HTTP, SSL
Affects Versions: 3.1.1, 3.1.0, 3.0.2
 Environment: RedHat Enterprise Linux 6.0, Intel 32-bit
Reporter: Wilson Ho
Priority: Blocker
 Fix For: 3.1.2

 Attachments: records.config


 A very reproducible bug where the body of a HTTPS POST request is never 
 forwarded to the origin server.
 Client submits a HTTPS POST request to TS, which is supposed to forward to 
 the backend/origin server via HTTP.  TS process the HTTP headers and 
 establishes connection to the origin server, but the body of the HTTPS POST 
 is never read.  This hangs until the client times out and shuts down the 
 connection.
 To reproduce:
 1) Client connects to TS using HTTPS (works OK if it is just HTTP).
 2) It must be a POST request.
 3) TS must use at least 2 worker threads.
 4) Easier to reproduce when the connections to the origin server is HTTP (not 
 HTTPS).
 5) POST body must be large enough so that the HTTP request headers and POST 
 body do *NOT* fit within the same TCP packet. (2000 bytes is a good size)
 6) I can consistently reproduce this problem using 2 separate clients each 
 simultaneously submitting 2 requests back to back (i.e., 2 requests from each 
 client, a total of 4 requests).  This gives you a high probability that at 
 least one of the requests would hang.
 Observation:
 1) Thread A accepted and processed the HTTP headers, and called 
 UnixNetProcessor::connect_re to prepare a new connection to the origin 
 server.
 2) Thread A must not have read the body of the POST.  Otherwise, it works 
 fine.
 3) Thread B was assigned the task to handle the origin server connection.  If 
 the same thread A was picked, then everything works fine.
 4) Apparently, one of the first things that thread B does is to acquire the 
 mutex for reading from the client.  (Why does it do that??)
 5) While thread B was holding the mutex, thread A proceeded in 
 SSLNetVConnection::net_read_io, tried and failed to acquire the mutex.  
 Thread A typically re-tried calling SSLNetVConnection::net_read_io soon, 
 but gave up after the second failure. But if thread B released the mutex soon 
 enough, that thread A could proceed happily and everything works.
 6) From this point, the body of the POST is never read from the client, and 
 there is nothing to be proxy'd to the origin server, and both the consumer 
 and producer tasks are never scheduled to run again -- or until the client 
 times out.  I tried setting the client-side time out to as long as 3-5 
 minutes and TS really does not recover by itself until the client closed the 
 connection.
 This is the first time I uses this bug system.  Please let me know how I 
 could produce the configuration files and trace logs, etc.  Thanks!

--
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-1053) get combo_handler compiled

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1053:
--

Fix Version/s: 3.1.2

 get combo_handler compiled
 --

 Key: TS-1053
 URL: https://issues.apache.org/jira/browse/TS-1053
 Project: Traffic Server
  Issue Type: Task
  Components: Plugins
Reporter: Conan Wang
 Fix For: 3.1.2

 Attachments: Makefile, combo_handler.diff, fetcher.diff


 combo_handler require ESI's code. Before make ESI work as a lib, you can try 
 it this way:
 make esi/lib and esi/fetcher the subdir of combo_handler and use the 
 makefile.
 {noformat} 
 combo_handler
 |combo_handler.cc
 |fetcher
 |lib
 |LICENSE
 |Makefile
 |README
 {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-1054) TSFetchUrl takes an address but does the DNS lookup anyway

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1054:
--

Fix Version/s: 3.1.2

 TSFetchUrl takes an address but does the DNS lookup anyway
 --

 Key: TS-1054
 URL: https://issues.apache.org/jira/browse/TS-1054
 Project: Traffic Server
  Issue Type: Bug
  Components: Performance
Affects Versions: 3.0.2
Reporter: James Peach
Priority: Minor
 Fix For: 3.1.2


 TSFetchUrl() takes an IP address as one of its arguments, so the API client 
 has to resolve the hostname portion of any URL it wants to fetch. However 
 once you get into the HTTP state machine, the host gets resolved again. One 
 of these DNS queries is redundant for performance reasons. Additionally, the 
 plugin might have some special knowledge about which IP address to use that 
 the DNS resolver doesn't, in which case the result would be wrong.
 [Dec 14 20:36:29.414] Server {0x7fff7b5f9960} DIAG: (plugin) [1] http request 
 (90 of 90 bytes):
 GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
 accept: */*
 [Dec 14 20:36:29.415] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [init] FetchSM 
 initialized for request with headers
 --
 GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
 accept: */*
 --
 [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [httpConnect] 
 calling httpconnect write
 [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Created 
 PluginVCCore at 0x102872c00, active 0x102872c38, passive 0x102872e10
 [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (http_seq) 
 HttpAccept:mainEvent] accepted connection
 [Dec 14 20:36:29.425] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] session 
 born, netvc 0x102872e10
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] using 
 accept inactivity timeout [120 seconds]
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] Starting 
 transaction 1 using sm [0]
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 do_io_read for 0 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 do_io_read for -1 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 do_io_read for -1 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 do_io_write for 90 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Passive: 
 Received event 1
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side; act_on 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 closed? 0 shutdown? 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Active: 
 Received event 1
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_read_side
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_read_side; act_on 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 closed? 0 shutdown? 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_write_side
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_write_side; act_on 90
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_write_side; added 90
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM) 
 [fetch_handler] calling fetch_plugin
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM) 
 [process_fetch_write] calling process write
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side; act_on 90
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side; added 90
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] 
 [HttpSM::main_handler, VC_EVENT_READ_READY]
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] 
 [HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] done parsing 
 client request header
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 reenable Read
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) START 
 HttpTransact::ModifyRequest
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) 
 [ink_cluster_time] local: 1323923789, highest_delta: 0, cluster: 1323923789
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) END 
 HttpTransact::ModifyRequest
 [Dec 14 20:36:29.437] Server 

[jira] [Updated] (TS-1052) trafficserver restart does not work (needs to let old process die)

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1052:
--

Fix Version/s: 3.1.2

 trafficserver restart does not work (needs to let old process die)
 --

 Key: TS-1052
 URL: https://issues.apache.org/jira/browse/TS-1052
 Project: Traffic Server
  Issue Type: Bug
  Components: Management
Affects Versions: 3.1.2
 Environment: Ubuntu 11.10 64bit
Reporter: Billy Vierra
Priority: Minor
 Fix For: 3.1.2

 Attachments: trafficserver.diff


 'bin/trafficserver restart' does not wait for the old process to stop thus 
 causing the restart to fail. 
 In my testing this takes from 5-8sec to happen.

--
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-1056) Lost UA connections can show up as 400 ERR_INVALID_REQ in logs

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1056:
--

Attachment: HttpSM.diff

 Lost UA connections can show up as 400 ERR_INVALID_REQ in logs
 

 Key: TS-1056
 URL: https://issues.apache.org/jira/browse/TS-1056
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 3.1.2

 Attachments: HttpSM.diff


 So, it seems that with Firefox (it's the only one I've been able to reproduce 
 this with), we can end up getting a bunch of errors like
 {code}
 1324075013.826 0 216.239.45.4 ERR_INVALID_REQ/400 217 - / - NONE/- text/html -
 {code}
 Tracking this down, it seems the HTTP SM is getting a VC_EVENT_EOS (stream 
 closed) in state_read_client_request_header(). However, there is nothing in 
 the request_header (zero bytes), so when it tries to parse the (empty) 
 request header, it looks like a request error.
 I'm not certain, yet at least, under what conditions we get this event (I'm 
 fairly certain that Firefox is somehow closing down the connection in some 
 weird state to us?). So, I'm suggesting we at least deal with this situation 
 earlier (before trying to parse the headers), which will instead cause an 
 UNKNOWN_ERROR (since we have no request nor response code. Suggested 
 changes attached.

--
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-1055) Wrong implementation of TSHttpSsnArgGet

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1055:
--

Fix Version/s: (was: 3.1.1)
   3.1.2

 Wrong implementation of TSHttpSsnArgGet
 ---

 Key: TS-1055
 URL: https://issues.apache.org/jira/browse/TS-1055
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
Assignee: Leif Hedstrom
  Labels: api-change
 Fix For: 3.1.2

   Original Estimate: 24h
  Remaining Estimate: 24h

 There is a different between the interface of TSHttpSsnArgGet and it 
 implemenation.
 In the interface (proxy/api/ts/ts.h.in):
  tsapi void* TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx);
 In the implementation(proxy/InkAPI.cc):
   void * TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
 So, I wrote a simple patch to fix this problem:
 Index: InkAPI.cc
 ===
 --- InkAPI.cc   (revision 1220421)
 +++ InkAPI.cc   (working copy)
 @@ -5500,7 +5500,7 @@
  }
  void *
 -TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx, void **argp)
 +TSHttpSsnArgGet(TSHttpSsn ssnp, int arg_idx)
  {
sdk_assert(sdk_sanity_check_http_ssn(ssnp) == TS_SUCCESS);
sdk_assert(arg_idx = 0  arg_idx  HTTP_SSN_TXN_MAX_USER_ARG);

--
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-1050) Cached objects become inaccessible when new volumes are added to the cache.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1050:
--

Fix Version/s: 3.3.0

 Cached objects become inaccessible when new volumes are added to the cache.
 ---

 Key: TS-1050
 URL: https://issues.apache.org/jira/browse/TS-1050
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Affects Versions: 3.1.1
Reporter: B Wyatt
 Fix For: 3.3.0


 During the investigation of TS-949 it came to light that even a consistent 
 hashing solution fails to maintain access for all objects in the cache when a 
 new volume is added.  This is because a new volume will necessarily assume 
 ownership for some portion of the object/hash space.  As a side effect of 
 this ownership change, new searches for previously cached objects may return 
 the new owner instead of the previous owner (which retained the cached copy). 
  According to the volume itself (and thus several aggregate statistics like 
 cache space usage), the objects are still valid and will remain as effective 
 dead weight until evicted during the normal cache operation.
 See comments on TS-949 for initial discussion of possible solutions.

--
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-999) Deprecate TSUrlDestroy ?

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-999:
-

Fix Version/s: (was: 3.1.3)
   3.1.2

 Deprecate TSUrlDestroy ?
 

 Key: TS-999
 URL: https://issues.apache.org/jira/browse/TS-999
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 3.1.2


 This API is a complete no-op as of quite a while ago. Should we just 
 deprecate it? Or, does anyone foresee a future where we actually need to call 
 TSUrlDestroy? Alan?

--
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-1071) Debug statement in FetchSM broken

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1071:
--

Fix Version/s: 3.1.2

 Debug statement in FetchSM broken
 -

 Key: TS-1071
 URL: https://issues.apache.org/jira/browse/TS-1071
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.2, 3.0.1
Reporter: Brian Geffon
Assignee: Leif Hedstrom
Priority: Trivial
 Fix For: 3.1.2

 Attachments: fetchsm.patch


 While debugging FetchSM I noticed that a debug statement was broken:
 [Jan  4 15:02:49.889] Server {140737294432000} DEBUG: (FetchSM) 
 [get_info_from_buffer] total avail ld
 It's a missing % in the DEBUG, patch included, and tested:
 [Jan  4 15:14:11.349] Server {139899653895936} DEBUG: (FetchSM) 
 [get_info_from_buffer] total avail 24615

--
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-1070) replace and deprecate TSFetchURL()

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1070:
--

Fix Version/s: 3.1.2

 replace and deprecate TSFetchURL()
 --

 Key: TS-1070
 URL: https://issues.apache.org/jira/browse/TS-1070
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: James Peach
Priority: Minor
 Fix For: 3.1.2


 TSFetchURL() has a number of shortcomings:
 1. it's not cancellable
 2. the event delivery is bizarre
 3. it doesn't play nicely with the TSHttpHdr*() API.
 I propose the following API changes:
 typedef enum
 {
 ...
 TS_EVENT_FETCH_SUCCESS,
 TS_EVENT_FETCH_FAILURE
 } TSEvent;
 TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *, 
 TSFetchWakeUpOptions);
 TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and 
 MIME headers. If the HTTP method in the HTTP header is not GET, and a error 
 will be reported.
 The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS 
 or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will 
 be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet(). 
 For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error 
 code. Hopefully there is some existing precedent to follow.
 TSFetchResource() should be cancellable via the TSAction return value.
 I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we 
 eliminate this, I'd argue for a uint64_t flags parameter.

--
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-1074) PluginVC should schedule to the local queue instead of the external queue.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1074:
--

Fix Version/s: 3.1.2

 PluginVC should schedule to the local queue instead of the external queue.
 --

 Key: TS-1074
 URL: https://issues.apache.org/jira/browse/TS-1074
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.1
Reporter: Brian Geffon
Assignee: Leif Hedstrom
 Fix For: 3.1.2

 Attachments: PluginVC.patch


 In TS-867 a patch was introduced to resolve a crash that was appearing w/ 
 TSFetchURL, the patch would schedule events on the same thread if it is a net 
 thread, if not it will only then schedule with the event processor. If you're 
 scheduling on the same thread, wouldn't it be more efficient to place the 
 event directly on the local queue? It turns out that going to the 
 ExternalQueue under low load it would cause the event to become delayed. 
 Patch Attached.
 To best see the symptoms see complaints in (TS-912 and TS-1043). 
 I have verified that this patch fixes the 10ms symptom seen in TS-912 and 
 TS-1043.

--
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-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1073:
--

Fix Version/s: 3.1.2
 Assignee: Leif Hedstrom

 no_dns_just_forward_to_parent configuration parameter is ignored/not used.
 --

 Key: TS-1073
 URL: https://issues.apache.org/jira/browse/TS-1073
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS
Affects Versions: 3.0.2
 Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
 Fix For: 3.1.2


 I have two instances of trafficserver configured, one instance is configured 
 to use the second instance as a parent proxy using the following parameters 
 from the records.config:
 CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
 CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
 The parent config looks like this:
 dest_domain=.  parent=parent:8080  round_robin=false
 The no_dns_just_forward_to_parent is not used in the code and as a result dns 
 lookups are being performed in the child instance.
 The following code changes seem to fix this:
 proxy/http/HttpSM.cc
 @@ -6406,11 +6405,20 @@
  t_state.dns_info.lookup_success = true;
  call_transact_and_set_next_state(NULL);
  break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED  
 t_state.dns_info.lookup_success) {
 // Already set, and we don't have a parent proxy to lookup
 ink_assert(t_state.host_db_info.ip());
 Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup, 
 provided by plugin);
 call_transact_and_set_next_state(NULL);
 break;
 +  } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER 
 
 + t_state.http_config_param-no_dns_forward_to_parent){
 +
 +if(t_state.cop_test_page) {
 +t_state.host_db_info.ip() 
 =t_state.state_machine-ua_session-get_netvc()-get_local_ip();
 +}
 +
 +t_state.dns_info.lookup_success = true;
 +call_transact_and_set_next_state(NULL);
 +break;
}
  
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
 to avoid reverse ns lookups
 /proxy/http/HttpTransact.cc
 @@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9' 
   s-dns_info.lookup_name[0] = '0' 
   //(s-state_machine-authAdapter.needs_rev_dns() ||
 - ( host_rule_in_CacheControlTable() || 
 s-parent_params-ParentTable-hostMatch)) {
 + ( host_rule_in_CacheControlTable() || 
 s-parent_params-ParentTable-hostMatch) 
 + !s-http_config_param-no_dns_forward_to_parent) {
  // note, broken logic: ACC fudges the OR stmt to always be true,
  // 'AuthHttpAdapter' should do the rev-dns if needed, not here .
  TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
 I would like to have these changes applied to the repository if they look ok.
 I also created an empty resolv.conf and pointed ats to the empty file:
 CONFIG proxy.config.dns.resolv_conf STRING 
 /usr/local/etc/trafficserver/resolv.conf
 When these changes are applied the child instance no longer attempts to 
 perform dns lookups for the
 http requests that it receives. If they are not applied and the dns lookup it 
 slow or unreliable on the
 child then the http requests are blocked by the dns lookup within the child 
 trafficserver instance.

--
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-1036) Improve squid log compatibility

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1036:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

 Improve squid log compatibility 
 

 Key: TS-1036
 URL: https://issues.apache.org/jira/browse/TS-1036
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging
Reporter: Leif Hedstrom
 Fix For: 3.1.3


 See 
 https://github.com/mnot/squidpeek/commit/3874cb902f257974d16c8eae5fc5a77c6fafbf69
   for some differences, from mnot as well:
 all of the ERR_* ones
 squid does TCP_REFRESH_FAIL_HIT, you do TCP_REF_FAIL_HIT
 squid does TCP_CLIENT_REFRESH_MISS, you do TCP_CLIENT_REFRESH
 squid does TCP_SWAPFAIL_MISS, you do TCP_SWAPFAIL

--
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-993) Add OpenBSD support.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-993:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 Add OpenBSD support.
 

 Key: TS-993
 URL: https://issues.apache.org/jira/browse/TS-993
 Project: Traffic Server
  Issue Type: Improvement
 Environment: OpenBSD
Reporter: Piotr Sikora
Assignee: Leif Hedstrom
 Fix For: 3.1.3

 Attachments: 0001-Add-OpenBSD-support.patch


 Add OpenBSD support.

--
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-1053) get combo_handler compiled

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1053:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

 get combo_handler compiled
 --

 Key: TS-1053
 URL: https://issues.apache.org/jira/browse/TS-1053
 Project: Traffic Server
  Issue Type: Task
  Components: Plugins
Reporter: Conan Wang
 Fix For: 3.1.3

 Attachments: Makefile, combo_handler.diff, fetcher.diff


 combo_handler require ESI's code. Before make ESI work as a lib, you can try 
 it this way:
 make esi/lib and esi/fetcher the subdir of combo_handler and use the 
 makefile.
 {noformat} 
 combo_handler
 |combo_handler.cc
 |fetcher
 |lib
 |LICENSE
 |Makefile
 |README
 {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-801) Crash Report: enable update will triger Segmentation fault

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-801:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 Crash Report: enable update will triger Segmentation fault
 --

 Key: TS-801
 URL: https://issues.apache.org/jira/browse/TS-801
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 2.1.8
 Environment: v2.1.8 and update function enabled.
Reporter: Zhao Yongming
  Labels: update
 Fix For: 3.1.3


 {code}
 b13621367...@hotmail.com: NOTE: Traffic Server received Sig 11: Segmentation 
 fault
 /usr/local/ts/bin/traffic_server - STACK TRACE:
 b13621367...@hotmail.com: 
 /usr/local/ts/bin/traffic_server[0x5260c9]
 /lib64/libpthread.so.0[0x3088e0f4c0]
 [0x6e]
 /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
  (*)(HttpTransact::State*))+0x6e)[0x57e0e2]
 /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x18b)[0x57e369]
 /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
 /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
  (*)(HttpTransact::State*))+0x15e)[0x57e1d2]
 /usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x138)[0x56d9aa]
 /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
 /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
 /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
 /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
 /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
  (*)(HttpTransact::State*))+0x15e)[0x57e1d2]
 /usr/local/ts/bin/traffic_server(HttpSM::handle_api_return()+0x13b13621367...@hotmail.com:
  8)[0x56d9aa]
 /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x47)[0x5b5cc1]
 /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
 /usr/local/ts/bin/traffic_server(HttpSM::set_next_state()+0x64)[0x57e242]
 /usr/local/ts/bin/traffic_server(HttpUpdateSM::set_next_state()+0xad)[0x5b604b]
 /usr/local/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
  (*)(HttpTransact::State*))+0x15e)[0x57e1d2]
 /usr/local/ts/bin/traffic_server(HttpUpdateSM::handle_api_return()+0x36)[0x5b5cb0]
 /usr/local/ts/bin/traffic_server(HttpSM::do_api_callout()+0x3f)[0x582cc3]
 /usr/local/ts/bin/traffic_server(HttpSM::state_add_to_list(int, 
 void*)+0x2aa)[0x56a51c]
 /usr/local/ts/bin/traffic_server(HttpSM::main_handler(int, 
 void*)+0x2cb)[0x570c13]
 /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x6c)[0x4e0486]
 /usr/local/ts/bin/traffic_server(HttpUpdateSM::start_scheduled_update(Continuation*,
  HTTPHdr*)+0x168)[0x5b5c1c]
 /usr/local/ts/bin/traffic_server(UpdateSM::http_scheme(UpdateSM*)+0x335)[0x53599f]
 /usr/local/ts/bin/traffic_server(UpdateSM::HandleSMEvent(int, 
 Event*)+0x1ab)[0x535437]
 /usr/local/ts/bin/traffic_server(Continuation::handleEvent(int, 
 void*)+0x6c)[0x4e0486]
 /usr/local/ts/bin/traffic_server(EThread::process_event(Event*, 
 int)+0x12c)[0x6fa9dc]
 /usr/local/ts/bin/traffic_server(EThread::execute()+0x9b)[0x6fabef]
 /usr/local/ts/bin/traffic_server[0x6f9b4c]
 /lib64/libpthread.so.0[0x3088e077e1]
 /lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
 /lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
 /lib64/libc.so.6(clone+0x6d)[0x38584e18ed]
 [May 26 16:25:14.569] Manager {140030245394400} ERROR: 
 [LocalManager::-PollMgmtProcessServer] Server Process terminated due to Sig 
 11: Segmentation fault
 [May 26 16:25:14.569] Manager {140030245394400} ERROR:  (last system error 
 32: Broken pipe)
 [[May 26 16:25:14.569] Manager {140030245394400} ERROR: 
 [Alarms::-SignalAlarm] Server Process was reset
 [May 26 16:25:14.569] Manager {140030245394400} ERROR:  (last system error 
 32: Broken pipe)
 [May 26 16:25:15.577] Manager {140030245394400} NOTE: 
 [LocalManager::-StartProxy] Launching ts process
 {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-832) Crash Report: RecMessageMarshal_Realloc in cluster mode 2

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-832:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 Crash Report: RecMessageMarshal_Realloc in cluster mode 2
 -

 Key: TS-832
 URL: https://issues.apache.org/jira/browse/TS-832
 Project: Traffic Server
  Issue Type: Bug
  Components: Clustering, Core
Affects Versions: 3.1.0
 Environment: version trunk, aka v3.0 after, cluster mode set to 2( 
 management cluster ), --enable-debug
Reporter: Zhao Yongming
  Labels: cluster, realloc
 Fix For: 3.1.3


 here is two core dumps:
 {code}
 #0  0x003c33030265 in raise () from /lib64/libc.so.6
 (gdb) bt
 #0  0x003c33030265 in raise () from /lib64/libc.so.6
 #1  0x003c33031d10 in abort () from /lib64/libc.so.6
 #2  0x003c3306a84b in __libc_message () from /lib64/libc.so.6
 #3  0x003c33075421 in realloc () from /lib64/libc.so.6
 #4  0x2acf28ff4e01 in ink_realloc (ptr=Could not find the frame base 
 for ink_realloc.
 ) at ink_memory.cc:88
 #5  0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010, 
 record=0x2acf29248f50) at RecMessage.cc:350
 #6  0x006eced8 in send_push_message () at P_RecCore.i:154
 #7  0x006efef9 in sync_cont::sync (this=0x20034150, event=1, 
 e=0x20033d30) at RecProcess.cc:263
 #8  0x004d2c5f in Continuation::handleEvent (this=0x20034150, 
 event=1, data=0x20033d30) at I_Continuation.h:146
 #9  0x006f5f0b in EThread::execute (this=0x2b5d5010) at 
 UnixEThread.cc:287
 #10 0x006f5181 in spawn_thread_internal (a=0x200441b0) at 
 Thread.cc:88
 #11 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
 #12 0x003c330d3c2d in clone () from /lib64/libc.so.6
 (gdb) info f
 Stack level 0, frame at 0x41f4c3e0:
  rip = 0x3c33030265 in raise; saved rip 0x3c33031d10
  called by frame at 0x41f4c520
  Arglist at 0x41f4c3d0, args:
  Locals at 0x41f4c3d0, Previous frame's sp is 0x41f4c3e0
  Saved registers:
   rip at 0x41f4c3d8
 {code}
 {code}
 #0  0x0038aa230265 in raise () from /lib64/libc.so.6
 (gdb) bt
 #0  0x0038aa230265 in raise () from /lib64/libc.so.6
 #1  0x0038aa231d10 in abort () from /lib64/libc.so.6
 #2  0x0038aa26a84b in __libc_message () from /lib64/libc.so.6
 #3  0x0038aa275421 in realloc () from /lib64/libc.so.6
 #4  0x2ab28042ce01 in ink_realloc (ptr=Could not find the frame base 
 for ink_realloc.
 ) at ink_memory.cc:88
 #5  0x006f2835 in RecMessageMarshal_Realloc (msg=0x2b6d6010, 
 record=0x2ab280680f50) at RecMessage.cc:350
 #6  0x006eced8 in send_push_message () at P_RecCore.i:154
 #7  0x006efef9 in sync_cont::sync (this=0x16a6f150, event=1, 
 e=0x16a6ed30) at RecProcess.cc:263
 #8  0x004d2c5f in Continuation::handleEvent (this=0x16a6f150, 
 event=1, data=0x16a6ed30) at I_Continuation.h:146
 #9  0x006f5f0b in EThread::execute (this=0x2b5d5010) at 
 UnixEThread.cc:287
 #10 0x006f5181 in spawn_thread_internal (a=0x16a7f1b0) at 
 Thread.cc:88
 #11 0x0038aae064a7 in start_thread () from /lib64/libpthread.so.0
 #12 0x0038aa2d3c2d in clone () from /lib64/libc.so.6
 (gdb) info f
 Stack level 0, frame at 0x406b03e0:
  rip = 0x38aa230265 in raise; saved rip 0x38aa231d10
  called by frame at 0x406b0520
  Arglist at 0x406b03d0, args:
  Locals at 0x406b03d0, Previous frame's sp is 0x406b03e0
  Saved registers:
   rip at 0x406b03d8
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-902) Crash report: invalid ip range in remap.config crash server

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-902:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 Crash report: invalid ip range in remap.config crash server
 ---

 Key: TS-902
 URL: https://issues.apache.org/jira/browse/TS-902
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration, HTTP
Affects Versions: 3.1.0, 3.0.1
 Environment: TS 3.0.1
Reporter: Zhao Yongming
  Labels: crash
 Fix For: 3.1.3


 when I put a strage ip range, ie: src_ip=128.0.0.0-121.14.89.0 in remap ip 
 filtering, it will cause the server crash:
 {code}
 [TrafficServer] using root directory '/usr'
 [Aug  4 11:04:53.209] Manager {140564987967264} NOTE: 
 [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
 [Aug  4 11:04:53.209] Manager {140564987967264} NOTE: [Alarms::signalAlarm] 
 Server Process born
 [Aug  4 11:04:54.222] {46990117603664} STATUS: opened 
 /var/log/trafficserver/diags.log
 [Aug  4 11:04:54.224] {46990117603664} NOTE: updated diags config
 [Aug  4 11:04:54.225] Server {46990117603664} NOTE: cache clustering disabled
 [Aug  4 11:04:54.239] Server {46990117603664} NOTE: cache clustering disabled
 [Aug  4 11:04:54.343] Server {46990117603664} NOTE: logging initialized[7], 
 logging_mode = 1
 [Aug  4 11:04:54.345] Server {46990117603664} NOTE: PrefetchProcessor: 
 Started the prefetch processor
 [Aug  4 11:04:54.346] Server {46990117603664} WARNING: Could not add rule at 
 line #1; Aborting!
 [Aug  4 11:04:54.346] Server {46990117603664} WARNING: [ReverseProxy] Unable 
 to parse IP value in src_ip=128.0.0.0-121.14.89.0 at line 1
 FATAL: [ReverseProxy] Unable to parse IP value in 
 src_ip=128.0.0.0-121.14.89.0 at line 1
 /usr/bin/traffic_server - STACK TRACE: 
 /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal_va+0x9d)[0x3ab46127dd]
 /usr/lib64/trafficserver/libtsutil.so.3(ink_fatal+0x88)[0x3ab4612938]
 /usr/bin/traffic_server(_ZN10UrlRewrite10BuildTableEv+0x585)[0x580335]
 /usr/bin/traffic_server(_ZN10UrlRewriteC1EPKc+0x2fa)[0x58219a]
 /usr/bin/traffic_server(_Z18init_reverse_proxyv+0xec)[0x4de75c]
 /usr/bin/traffic_server(_Z20init_HttpProxyServerv+0xb)[0x51ee7b]
 /usr/bin/traffic_server(main+0xc07)[0x4bf177]
 /lib64/libc.so.6(__libc_start_main+0xf4)[0x389961d994]
 /usr/bin/traffic_server(__gxx_personality_v0+0x491)[0x4793a9]
 [Aug  4 11:04:54.506] Manager {140564987967264} ERROR: 
 [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6: 
 Aborted
 {code}
 and here is the rules defined in my remap.config:
 {code}
 .defflt  tools @action=deny @src_ip=0.0.0.0-127.0.0.0 
 @src_ip=128.0.0.0-121.14.89.0 @src_ip=121.14.90.254-255.255.255.255 
 @method=PURGE
 .useflt  tools
 {code}
 well, it is invalid, but we should not crash, right?

--
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-920) HTTP CONNECT gives bad request line

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-920:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 HTTP CONNECT gives bad request line
 ---

 Key: TS-920
 URL: https://issues.apache.org/jira/browse/TS-920
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: M. Nunberg
 Fix For: 3.1.3


 An HTTP CONNECT tunnel request such as:
 CONNECT foo.com:443 HTTP/1.1
 
 is translated into:
 CONNECT https://foo.com:443/ HTTP/1.1
 
 and is sent as such to a parent proxy when ATS is configured to forward 
 requests to parent proxy. This can break the parent proxy in some (all?) 
 cases, since the semi-standard for CONNECT is a host specification, not a URI.
 In practice, for most applications, this issue is quite rare since it is 
 often pointless to forward CONNECT requests, unless the parent proxy does 
 some special handling or man-in-the-middle operations etc.

--
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-993) Add OpenBSD support.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-993:
-

Fix Version/s: 3.3.0
 Assignee: (was: Leif Hedstrom)

Moving out to v3.3.0, please move back if/when you have fixes for this.

 Add OpenBSD support.
 

 Key: TS-993
 URL: https://issues.apache.org/jira/browse/TS-993
 Project: Traffic Server
  Issue Type: Improvement
 Environment: OpenBSD
Reporter: Piotr Sikora
 Fix For: 3.3.0, 3.1.3

 Attachments: 0001-Add-OpenBSD-support.patch


 Add OpenBSD support.

--
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-1033) Add some missing WKS's to HdrToken.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1033:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

 Add some missing WKS's to HdrToken.
 -

 Key: TS-1033
 URL: https://issues.apache.org/jira/browse/TS-1033
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 3.1.3


 And of course various other places (including InkAPI).

--
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-1046) Add possibility to extend tsxs command line for -Iincludes

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1046:
--

Backport to Version: 3.0.3  (was: 3.0.2)

Moving to 3.0.3, I don't think think this got into 3.0.2, right ?

 Add possibility to extend tsxs command line for -Iincludes
 --

 Key: TS-1046
 URL: https://issues.apache.org/jira/browse/TS-1046
 Project: Traffic Server
  Issue Type: Improvement
  Components: Build
Affects Versions: 3.1.1, 3.0.2
Reporter: Igor Galić
Assignee: Igor Galić
 Fix For: 3.1.2


 Already commited in r1212075

--
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-1060) fail assert at CacheVC::handleReadDone

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1060:
--

Fix Version/s: (was: 3.0.2)
   3.1.3

 fail assert at CacheVC::handleReadDone
 --

 Key: TS-1060
 URL: https://issues.apache.org/jira/browse/TS-1060
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, HTTP
Affects Versions: 3.0.1
 Environment: v3.0.x, with some patch from taobao
Reporter: Zhao Yongming
Assignee: Zhao Yongming
  Labels: crash
 Fix For: 3.1.3


 {code}
 #0  0x003f96032a45 in raise () from /lib64/libc.so.6
 #1  0x003f96034225 in abort () from /lib64/libc.so.6
 #2  0x2b0dea6f6394 in ink_die_die_die (retval=1) at ink_error.cc:43
 #3  0x2b0dea6f6466 in ink_fatal_va(int, const char *, typedef 
 __va_list_tag __va_list_tag *) (return_code=1, 
 message_format=0x2b0deb9ed240 Cache.cc:1959: failed assert `((Doc *) 
 buf-data())-magic == DOC_MAGIC`, ap=0x2b0deb9ed140) at ink_error.cc:65
 #4  0x2b0dea6f6531 in ink_fatal (return_code=1, 
 message_format=0x2b0deb9ed240 Cache.cc:1959: failed assert `((Doc *) 
 buf-data())-magic == DOC_MAGIC`) at ink_error.cc:73
 #5  0x2b0dea6f4ece in _ink_assert (a=0x773770 ((Doc *) 
 buf-data())-magic == DOC_MAGIC, f=0x7726be Cache.cc, l=1959) at 
 ink_assert.cc:44
 #6  0x0069429a in CacheVC::handleReadDone (this=0x3d51710, 
 event=3900, e=0x0) at Cache.cc:1959
 #7  0x004e02fa in Continuation::handleEvent (this=0x3d51710, 
 event=3900, data=0x0) at ../iocore/eventsystem/I_Continuation.h:146
 #8  0x006b7715 in Cache::open_read (this=0x3aeaf00, 
 cont=0x2b0e20737fa8, key=0x2b0deb9ed9c0, request=0x2b0e207365d0, 
 params=0x2b0e20735e08, 
 type=CACHE_FRAG_TYPE_HTTP, 
 hostname=0x2b0e300458cb 
 img01.taobaocdn.combao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpgimg01.taobaocdn.comhttp://img01.taobaocdn.com/bao/uploaded/i1/T1701bXfdDXXaCZpA__104916.jpg_160x160.jpg;,
  host_len=19) at CacheRead.cc:231
 #9  0x0069cfcf in Cache::open_read (this=0x3aeaf00, 
 cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0, 
 params=0x2b0e20735e08, 
 type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1080
 #10 0x0069a9f6 in CacheProcessor::open_read (this=0xf44d30, 
 cont=0x2b0e20737fa8, url=0x2b0e207365e8, request=0x2b0e207365d0, 
 params=0x2b0e20735e08, 
 pin_in_cache=0, type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3041
 #11 0x0055937c in HttpCacheSM::do_cache_open_read 
 (this=0x2b0e20737fa8) at HttpCacheSM.cc:220
 #12 0x005594cd in HttpCacheSM::open_read (this=0x2b0e20737fa8, 
 url=0x2b0e207365e8, hdr=0x2b0e207365d0, params=0x2b0e20735e08, pin_in_cache=0)
 at HttpCacheSM.cc:252
 #13 0x0057802d in HttpSM::do_cache_lookup_and_read 
 (this=0x2b0e20735d10) at HttpSM.cc:3911
 #14 0x005808d6 in HttpSM::set_next_state (this=0x2b0e20735d10) at 
 HttpSM.cc:6455
 #15 0x005801fa in HttpSM::call_transact_and_set_next_state 
 (this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
 #16 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at 
 HttpSM.cc:1519
 #17 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at 
 HttpSM.cc:502
 #18 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at 
 HttpSM.cc:6380
 #19 0x005801fa in HttpSM::call_transact_and_set_next_state 
 (this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
 #20 0x00580391 in HttpSM::set_next_state (this=0x2b0e20735d10) at 
 HttpSM.cc:6396
 #21 0x005801fa in HttpSM::call_transact_and_set_next_state 
 (this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
 #22 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at 
 HttpSM.cc:1519
 #23 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at 
 HttpSM.cc:502
 #24 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at 
 HttpSM.cc:6380
 #25 0x005801fa in HttpSM::call_transact_and_set_next_state 
 (this=0x2b0e20735d10, f=0) at HttpSM.cc:6346
 #26 0x0056f82a in HttpSM::handle_api_return (this=0x2b0e20735d10) at 
 HttpSM.cc:1519
 #27 0x00585eb5 in HttpSM::do_api_callout (this=0x2b0e20735d10) at 
 HttpSM.cc:502
 #28 0x0058026a in HttpSM::set_next_state (this=0x2b0e20735d10) at 
 HttpSM.cc:6380
 #29 0x005801fa in HttpSM::call_transact_and_set_next_state 
 (this=0x2b0e20735d10, f=0x58f002 
 HttpTransact::ModifyRequest(HttpTransact::State*))
 at HttpSM.cc:6346
 #30 0x0056d45a in HttpSM::state_read_client_request_header 
 (this=0x2b0e20735d10, event=100, data=0x2b0e440157c8) at HttpSM.cc:783
 #31 0x0056caf5 in HttpSM::setup_client_read_request_header 
 (this=0x2b0e20735d10) at HttpSM.cc:645
 #32 0x0056f74c in 

[jira] [Updated] (TS-990) IPv6 support for clustering

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-990:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 IPv6 support for clustering
 ---

 Key: TS-990
 URL: https://issues.apache.org/jira/browse/TS-990
 Project: Traffic Server
  Issue Type: Improvement
  Components: Clustering
Affects Versions: 3.1.0
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
  Labels: clustering, ipv6
 Fix For: 3.1.3


 Update clustering to be IPv6 compatible.

--
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-1058) Intercept an HTTP client's request

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1058:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

 Intercept an HTTP client's request
 --

 Key: TS-1058
 URL: https://issues.apache.org/jira/browse/TS-1058
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.1.1
Reporter: Yakov Kopel
  Labels: patch
 Fix For: 3.1.3

 Attachments: patch.diff

   Original Estimate: 24h
  Remaining Estimate: 24h

 I want that the trafficserver will give the client the response instead of 
 the server.
 The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not 
 so convenience to use it.
 I want to use the regular flow of the trafficserver, and its regular parsing 
 commands.
 The trafficserver's plugins examples also aren't using the 
 INKHttpTxnIntercept , but they rather using the rasing error method, and 
 then they response the request at the response hook.
 So, this is whta i did.
 On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised 
 TS_EVENT_HTTP_ERROR.
 I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http 
 response with the KEEP-ALIVE header.
 The problem is that the trafficserver is closing the connection although i 
 added to the response the KEEP-ALIVE header.
  
 When the Trafficserver is trying to send response to the client, it terminate 
 the session after it.
 Although I added the KEEP-ALIVE mime field - it didn't work.
 The debug dump is looking like this:
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
 [HttpSM::state_api_callback, HTTP_API_CONTINUE]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
 [HttpSM::state_api_callout, HTTP_API_CONTINUE]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
 [HttpSM::do_redirect]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
 [HttpTunnel::deallocate_postdata_copy_buffers]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] 
 adding producer 'internal msg'
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] 
 adding consumer 'user agent'
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) 
 tunnel_run started, p_arg is NULL
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4] 
 consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
 [HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session 
 closed
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session 
 destroy
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
 [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] 
 [HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect) 
 [HttpTunnel::deallocate_postdata_copy_buffers]
   [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling 
 plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
 The Solution:
 I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE, 
 so the trafficserver will realy believe us that we want to keep this 
 connection alive :)
 Example for the usage of the new function:
   // Tell the trafficserver to not close this connection (keep-alive)
   TSHttpTxnCloseAfterResponse(txnp, 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-1019) clean up access to librecords and remove wrappers

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1019:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

 clean up access to librecords and remove wrappers
 -

 Key: TS-1019
 URL: https://issues.apache.org/jira/browse/TS-1019
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: Bryan Call
Assignee: Igor Galić
Priority: Minor
 Fix For: 3.1.3


 There are unneeded define wrappers around the librecord function calls: 
 {noformat}
 [bcall@Bryan-Calls-MacBook-Pro-3 traffic.git]$ grep -r REC_ConfigReadInteger 
 * | grep define
 iocore/eventsystem/P_EventSystem.h:#define IOCORE_ConfigReadInteger   
  REC_ConfigReadInteger
 proxy/http/HttpConfig.h:#define HTTP_ConfigReadInteger 
 REC_ConfigReadInteger
 proxy/logging/LogConfig.h:#define LOG_ConfigReadInteger 
 REC_ConfigReadInteger
 proxy/logging/LogConfig.h:#define LOG_LocalReadInteger  
 REC_ConfigReadInteger
 proxy/Main.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
 proxy/Prefetch.h:#define TS_ConfigReadIntegerREC_ConfigReadInteger
 proxy/Update.cc:#define UPDATE_ConfigReadInteger REC_ConfigReadInteger
 {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-981) ATS as transparent proxy crashes under heavy load

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-981:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 ATS as transparent proxy crashes under heavy load
 -

 Key: TS-981
 URL: https://issues.apache.org/jira/browse/TS-981
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.0
 Environment: 4 core desktop. Centos 5.6, kernel 2.6.39.2 compiled 
 with TPROXY support.
 ATS compiled as: ./configure --enable-tproxy --enable-libev
Reporter: Danny Shporer
Priority: Critical
 Fix For: 3.1.3

 Attachments: records.config


 ATS crashes under heavy load testing - around 25,000 HTTP transactions per 
 second.
 I have tested it on both vesions 3.0.0 and 3.0.1 and the same happens.
 GDB info:
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x42174940 (LWP 6663)]
 0x0068fd4b in modify (this=0x2b12c628, event=value optimized 
 out, e=value optimized out) at P_UnixNet.h:536
 536 fd_change(event_loop-eio, eio.fd, 0);
 (gdb) bt
 #0  0x0068fd4b in modify (this=0x2b12c628, event=value optimized 
 out, e=value optimized out) at P_UnixNet.h:536
 #1  NetHandler::mainNetEvent (this=0x2b12c628, event=value optimized 
 out, e=value optimized out) at UnixNet.cc:432
 #2  0x006bfc4f in EThread::process_event (this=0x2b12b010, 
 e=0xf44570, calling_code=5) at I_Continuation.h:146
 #3  0x006c055c in EThread::execute (this=0x2b12b010) at 
 UnixEThread.cc:262
 #4  0x006bef8e in spawn_thread_internal (a=0xf35c90) at Thread.cc:88
 #5  0x003e9dc0673d in start_thread () from /lib64/libpthread.so.0
 #6  0x003e9d0d44bd in clone () from /lib64/libc.so.6
 (gdb) info f
 Stack level 0, frame at 0x42174030:
  rip = 0x68fd4b in modify (P_UnixNet.h:536); saved rip 0x6bfc4f
  inlined into frame 1
  source language c++.
  Arglist at unknown address.
  Locals at unknown address, Previous frame's sp in rsp

--
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-1015) TSEvent is widely declared as int

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1015:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

 TSEvent is widely declared as int
 -

 Key: TS-1015
 URL: https://issues.apache.org/jira/browse/TS-1015
 Project: Traffic Server
  Issue Type: Bug
Reporter: Nick Kew
Priority: Minor
 Fix For: 3.1.3


 TSEvent is an enum, defined in ts.h.  But in much of the code, TSEvent is 
 declared as type int.  This makes it harder to follow/debug using tools like 
 *trace or gdb.
 This may usefully be fixed as and when people encounter instances of it.

--
This message 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-995) Change IPv6 support function names to be clearer and more compliant.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-995:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 Change IPv6 support function names to be clearer and more compliant.
 

 Key: TS-995
 URL: https://issues.apache.org/jira/browse/TS-995
 Project: Traffic Server
  Issue Type: Improvement
  Components: Network
Affects Versions: 3.1.0
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
 Fix For: 3.1.3


 Several changes:
 1) Change ink_inet to ats_ip.
 2) Except for a few test functions, ats_is_ip, ats_is_ip4, ats_is_ip6.
 3) Change the current cmp and eq functions to cmp_addr and eq_addr to 
 reduce confusion about whether the port is compared as well.

--
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-561) Origin-server side IPv6 support

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-561:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 Origin-server side IPv6 support
 ---

 Key: TS-561
 URL: https://issues.apache.org/jira/browse/TS-561
 Project: Traffic Server
  Issue Type: New Feature
  Components: Network
 Environment: Linux 4.x
Reporter: Anirban Roy
Assignee: Alan M. Carroll
 Fix For: 3.1.3


 raffic Server used as forward proxy in a number of places including web 
 crawling and feed fetching applications. In those applications, 
 (origin)server side IPv6 support is desirable. As the Internet running out of 
 IPv4 addresses, the new sites will run on IPv6 stack. The applications 
 pulling content using traffic server should be able to do so in the changing 
 scenario.

--
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-977) RecCore usage cleanup

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-977:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 RecCore usage cleanup
 -

 Key: TS-977
 URL: https://issues.apache.org/jira/browse/TS-977
 Project: Traffic Server
  Issue Type: Task
  Components: Cleanup
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Minor
 Fix For: 3.1.3


 in RecCore.*
 {code}
 int RecGetRecordInt(const char *name, RecInt * rec_int, bool lock = true);
 //-
 // RecGetRecordXXX
 //-
 int
 RecGetRecordInt(const char *name, RecInt *rec_int, bool lock)
 {
   int err;
   RecData data;
   if ((err = RecGetRecord_Xmalloc(name, RECD_INT, data, lock)) == 
 REC_ERR_OKAY)
 *rec_int = data.rec_int;
   return err;
 }
 {code}
 and there is something heavy used:
 {code}
 //-
 // Backwards Compatibility Items (REC_ prefix)
 //-
 #define REC_ReadConfigInt32(_var,_config_var_name) do { \
   RecInt tmp = 0; \
   RecGetRecordInt(_config_var_name, (RecInt*) tmp); \
   _var = (int32_t)tmp; \
 } while (0)
 #define REC_ReadConfigInteger(_var,_config_var_name) do { \
   RecInt tmp = 0; \
   RecGetRecordInt(_config_var_name, tmp); \
   _var = tmp; \
 } while (0)
 {code}
 and a real case, the REC_ReadConfigInteger is renamed to 
 IOCORE_ReadConfigInteger:
 {code}
 RecInt cache_config_threads_per_disk = 12;
 #define IOCORE_ReadConfigIntegerREC_ReadConfigInteger
   IOCORE_ReadConfigInteger(cache_config_threads_per_disk, 
 proxy.config.cache.threads_per_disk);
 {code}
 my question is, why it is so complex in all these renaming? why not just:
 {code}
 RecGetRecordInt(proxy.config.cache.threads_per_disk, 
 cache_config_threads_per_disk);
 {code}
 brief talk with Leif, we may need to cleanup the use of REC_*. make it a 
 small task here

--
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-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-968:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

 During/after daily logfile roll, trafficserver seg faults (Sig 11)
 --

 Key: TS-968
 URL: https://issues.apache.org/jira/browse/TS-968
 Project: Traffic Server
  Issue Type: Bug
  Components: Logging
Affects Versions: 3.0.1
 Environment: Ubuntu 10.10, 2.6.35-24-virtual
Reporter: Drew Rothstein
 Fix For: 3.1.3


 Every day at 00:00:00 after/during the log file roll, I see a segfault.  Here 
 are the past couple days:
 [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile 
 /usr/local/var/log/trafficserver/error.log was rolled to 
 /usr/local/var/log/trafficserver/error.log_trafficserver02.20110921.00h00m06s-20110922.00h00m00s.old.
 [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile 
 /usr/local/var/log/trafficserver/squid.log was rolled to 
 /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
 [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile 
 /usr/local/var/log/trafficserver/extended2.log was rolled to 
 /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/bin/traffic_server - STACK TRACE: 
 [Sep 22 00:00:17.729] Manager {140722071643936} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Sep 22 00:00:17.729] Manager {140722071643936} FATAL:  (last system error 
 104: Connection reset by peer)
 [Sep 22 00:00:17.730] Manager {140722071643936} NOTE: 
 [LocalManager::mgmtShutdown] Executing shutdown request.
 [Sep 22 00:00:17.730] Manager {140722071643936} NOTE: 
 [LocalManager::processShutdown] Executing process shutdown request.
 [Sep 22 00:00:17.730] Manager {140722071643936} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 [Sep 22 00:00:17.730] Manager {140722071643936} ERROR:  (last system error 
 32: Broken pipe)
 [E. Mgmt] log == [TrafficManager] using root directory '/usr/local'
 [Sep 22 00:00:17.786] {140131209512736} STATUS: opened 
 /usr/local/var/log/trafficserver/manager.log
 [Sep 22 00:00:17.786] {140131209512736} NOTE: updated diags config
 [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: 
 [ClusterCom::ClusterCom] Node running on OS: 'Linux' Release: 
 '2.6.35-24-virtual'
 [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: 
 [LocalManager::listenForProxy] Listening on port: 80
 [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: [TrafficManager] Setup 
 complete
 [Sep 22 00:00:18.827] Manager {140131209512736} NOTE: 
 [LocalManager::startProxy] Launching ts process
 [TrafficServer] using root directory '/usr/local'
 [Sep 22 00:00:18.849] Manager {140131209512736} NOTE: 
 [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
 [Sep 22 00:00:18.849] Manager {140131209512736} NOTE: [Alarms::signalAlarm] 
 Server Process born
 [Sep 22 00:00:19.874] {47510015031936} STATUS: opened 
 /usr/local/var/log/trafficserver/diags.log
 [Sep 22 00:00:19.874] {47510015031936} NOTE: updated diags config
 [Sep 22 00:00:19.879] Server {47510015031936} NOTE: cache clustering disabled
 [Sep 22 00:00:19.908] Server {47510015031936} NOTE: cache clustering disabled
 [Sep 22 00:00:20.019] Server {47510015031936} NOTE: logging initialized[7], 
 logging_mode = 3
 [Sep 22 00:00:20.032] Server {47510015031936} NOTE: traffic server running
 [Sep 22 00:00:20.045] Server {47510028859136} NOTE: cache enabled
 [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile 
 /usr/local/var/log/trafficserver/error.log was rolled to 
 /usr/local/var/log/trafficserver/error.log_trafficserver02.20110922.00h00m11s-20110923.00h00m00s.old.
 [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile 
 /usr/local/var/log/trafficserver/squid.log was rolled to 
 /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
 [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile 
 /usr/local/var/log/trafficserver/extended2.log was rolled to 
 /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
 NOTE: Traffic Server received Sig 11: Segmentation fault
 /usr/local/bin/traffic_server - STACK TRACE: 
 [Sep 23 00:00:14.668] Manager {140131209512736} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 [Sep 23 00:00:14.668] Manager {140131209512736} FATAL:  (last system error 
 104: Connection reset by peer)
 [Sep 23 00:00:14.668] Manager {140131209512736} NOTE: 
 [LocalManager::mgmtShutdown] Executing shutdown request.
 

[jira] [Updated] (TS-1002) log unmapped HOST when pristine_host_hdr disabled

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1002:
--

Fix Version/s: (was: 3.1.2)
   3.1.4

This is unfortunately how it works (currently). I'm thinkign, we might want to 
make a copy of the pristine request header object before remapping, clean out 
all the code around logging the pristine data, and add another directive to 
logging to get components out of this (new) pristine host header object.

Moving this out to 3.1.4 for now.

 log unmapped HOST when pristine_host_hdr disabled
 -

 Key: TS-1002
 URL: https://issues.apache.org/jira/browse/TS-1002
 Project: Traffic Server
  Issue Type: Wish
  Components: Logging
Reporter: Conan Wang
Priority: Minor
 Fix For: 3.1.4


 I want to log user request's Host in http header before remap. I write 
 logs_xml.config, like:  %{Host}cqh
 When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the 
 right Host which is not rewritten.
 When disable the config, I always get the rewritten/mapped Host which is 
 not what I need.
 logs_xml reference: 
 http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912

--
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-921) TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the Transfer Encoding: chunked http header !

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-921:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

Looking for someone who wish to work on this (if so, just take it / assign it). 
Moving out unassigned bugs with no patches etc. to 3.1.3 for now.

 TSIOBufferBlockReadStart() could'nt return the corresponding chunk data 
 length when original server using the Transfer Encoding: chunked http 
 header !
 

 Key: TS-921
 URL: https://issues.apache.org/jira/browse/TS-921
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.1
 Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1, 
 Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, 
 HardDisk: 500G
Reporter: taoyunxing
  Labels: transfer_encoding_chunded
 Fix For: 3.1.3

   Original Estimate: 672h
  Remaining Estimate: 672h

 Recently I meet with a strange proble when I manage to get the server 
 response body in the Transfer Encoding: chunked mode: 
 I couldn't get the corresponding chunk length in hexdecimal ! The details as 
 follows:
 I use the null-transform plugin modified to just output the server response 
 body, when the web server uses  the Transfer Encoding: chunked header
 to transfer chunked data to user agent, eg, I request the web page: 
 http://www.qq.com/;, I just get the chunk body data, but get no chunk length 
 in 
 the hexdecimal format 383cb\r\n before the chunk body data. the chunk body 
 data is uncompressed and like as !DOCTYPE html PUBLIC -//W3C//DTD XHTML 
 1.0 Transitional//EN 
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n...
 In addition, I capture the data packet using the Wireshark software, I sure 
 that I see the chunk length  383cb\r\n before the chunk body data  
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;\r\n..., it is 
 a complete chunk response !
 I continue to check the code of null-transform.c, set a breakpoint at the 
 function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at 
 the breakpoint TSIOBufferBlockReadStart(),  I print the return string of 
 TSIOBufferBlockReadStart(), there is no chunk data length at the head of 
 output string, which implies the api TSIOBufferBlockReadStart() has bug！ 
 Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330, 
 avail=0xb6c8e288) at InkIOCoreAPI.cc:659
 659   {
 (gdb) s
 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
 (gdb) n
 667 p = blk-start();
 (gdb) 
 668 if (avail)
 (gdb) p p
 $3 = 0xb1312000 !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 
 Transitional//EN\ 
 \http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml 
 xmlns=\http://www.w3.org/1999/xhtml\;\r\nhead\r\nmeta 
 http-equiv=\Conten...
 (gdb)

--
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-1048) Add TS API to enable plugins to use traffic server configuration infrastructure

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1048:
--

Issue Type: New Feature  (was: Improvement)

 Add TS API to enable plugins to use traffic server configuration 
 infrastructure 
 

 Key: TS-1048
 URL: https://issues.apache.org/jira/browse/TS-1048
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration, TS API
 Environment: Centos 6
Reporter: bianca cooper
Assignee: Leif Hedstrom
Priority: Minor
  Labels: api-addition, configuration
 Fix For: 3.1.2

 Attachments: TS-1048.diff, diff.txt

   Original Estimate: 72h
  Remaining Estimate: 72h

 Export RecRegisterConfigInt and RecRegisterConfigString to enable adding a 
 configuration record to the records hashtable. 
 Once plugin new configuration records should be added, the addition will be 
 done by calling the API in the plugin code. No need to add the record to 
 RecordsConfig static array. No need to recompile the ATS each time. 

--
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-1007) SSN Close called before TXN Close

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1007:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

Looking for someone who wish to work on this (if so, just take it / assign it). 
Moving out unassigned bugs with no patches etc. to 3.1.3 for now.

 SSN Close called before TXN Close
 -

 Key: TS-1007
 URL: https://issues.apache.org/jira/browse/TS-1007
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.1
Reporter: Nick Kew
Priority: Critical
 Fix For: 3.1.3


 Where a plugin implements both SSN_CLOSE_HOOK and TXN_CLOSE_HOOK, the 
 SSN_CLOSE_HOOK is called first of the two.  This messes up normal cleanups!
 Details:
   Register a SSN_START event globally
   In the SSN START, add a TXN_START and a SSN_CLOSE
   In the TXN START, add a TXN_CLOSE
 Stepping through, I see the order of events actually called, for the simple 
 case of a one-off HTTP request with no keepalive:
 SSN_START
 TXN_START
 SSN_END
 TXN_END
 Whoops, SSN_END cleaned up the SSN context, leaving dangling pointers in the 
 TXN!

--
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-1045) PATCH: add new TSFetchHdrGet API

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1045:
--

Issue Type: New Feature  (was: Improvement)

 PATCH: add new TSFetchHdrGet API
 

 Key: TS-1045
 URL: https://issues.apache.org/jira/browse/TS-1045
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP
Reporter: James Peach
Assignee: Leif Hedstrom
Priority: Minor
 Fix For: 3.1.2

 Attachments: 0001-Add-new-public-API-TSFetchHdrGet.patch, 
 0007-Add-new-public-API-TSFetchHdrGet.patch, TS-1045-formatting.diff


 TSFetchUrl does not provide any way to get the headers from the result. This 
 patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() 
 and returns the headers.

--
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-1081) Eliminate the additional internal copy of the pristine URL string

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1081:
--

Attachment: TS-1081.diff

Proposed changes to eliminate the additional string reference to the pristine 
URL.

 Eliminate the additional internal copy of the pristine URL string
 ---

 Key: TS-1081
 URL: https://issues.apache.org/jira/browse/TS-1081
 Project: Traffic Server
  Issue Type: Improvement
  Components: HTTP
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 3.1.2

 Attachments: TS-1081.diff


 We have (at least) two copies of the pristine URL in the code. One is the 
 actual URL object (as used by the APIs), and one is a string reference to the 
 URL (char*). The latter is only used in a couple of places, primarily when 
 the cquuc tag is used in a custom log format. I propose that we eliminate 
 this additional string version of the pristine URL entirely.

--
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-961) Extend TS API to support TSNetAccept with inbound transparency

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-961:
-

Fix Version/s: (was: 3.1.2)
   3.1.3

Moving this out to 3.1.3, please move as necessary.

 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.3

 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-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1073:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

Moving out to v3.1.3, please move back if you think it will be done in the very 
near future.

 no_dns_just_forward_to_parent configuration parameter is ignored/not used.
 --

 Key: TS-1073
 URL: https://issues.apache.org/jira/browse/TS-1073
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS
Affects Versions: 3.0.2
 Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
 Fix For: 3.1.3

 Attachments: TS-1073.patch


 I have two instances of trafficserver configured, one instance is configured 
 to use the second instance as a parent proxy using the following parameters 
 from the records.config:
 CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
 CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
 The parent config looks like this:
 dest_domain=.  parent=parent:8080  round_robin=false
 The no_dns_just_forward_to_parent is not used in the code and as a result dns 
 lookups are being performed in the child instance.
 The following code changes seem to fix this:
 proxy/http/HttpSM.cc
 @@ -6406,11 +6405,20 @@
  t_state.dns_info.lookup_success = true;
  call_transact_and_set_next_state(NULL);
  break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED  
 t_state.dns_info.lookup_success) {
 // Already set, and we don't have a parent proxy to lookup
 ink_assert(t_state.host_db_info.ip());
 Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup, 
 provided by plugin);
 call_transact_and_set_next_state(NULL);
 break;
 +  } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER 
 
 + t_state.http_config_param-no_dns_forward_to_parent){
 +
 +if(t_state.cop_test_page) {
 +t_state.host_db_info.ip() 
 =t_state.state_machine-ua_session-get_netvc()-get_local_ip();
 +}
 +
 +t_state.dns_info.lookup_success = true;
 +call_transact_and_set_next_state(NULL);
 +break;
}
  
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
 to avoid reverse ns lookups
 /proxy/http/HttpTransact.cc
 @@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9' 
   s-dns_info.lookup_name[0] = '0' 
   //(s-state_machine-authAdapter.needs_rev_dns() ||
 - ( host_rule_in_CacheControlTable() || 
 s-parent_params-ParentTable-hostMatch)) {
 + ( host_rule_in_CacheControlTable() || 
 s-parent_params-ParentTable-hostMatch) 
 + !s-http_config_param-no_dns_forward_to_parent) {
  // note, broken logic: ACC fudges the OR stmt to always be true,
  // 'AuthHttpAdapter' should do the rev-dns if needed, not here .
  TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
 I would like to have these changes applied to the repository if they look ok.
 I also created an empty resolv.conf and pointed ats to the empty file:
 CONFIG proxy.config.dns.resolv_conf STRING 
 /usr/local/etc/trafficserver/resolv.conf
 When these changes are applied the child instance no longer attempts to 
 perform dns lookups for the
 http requests that it receives. If they are not applied and the dns lookup it 
 slow or unreliable on the
 child then the http requests are blocked by the dns lookup within the child 
 trafficserver instance.

--
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-1070) replace and deprecate TSFetchURL()

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1070:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

Moving out to 3.1.3 for now.

 replace and deprecate TSFetchURL()
 --

 Key: TS-1070
 URL: https://issues.apache.org/jira/browse/TS-1070
 Project: Traffic Server
  Issue Type: Improvement
  Components: TS API
Reporter: James Peach
Assignee: James Peach
Priority: Minor
 Fix For: 3.1.3


 TSFetchURL() has a number of shortcomings:
 1. it's not cancellable
 2. the event delivery is bizarre
 3. it doesn't play nicely with the TSHttpHdr*() API.
 I propose the following API changes:
 typedef enum
 {
 ...
 TS_EVENT_FETCH_SUCCESS,
 TS_EVENT_FETCH_FAILURE
 } TSEvent;
 TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *, 
 TSFetchWakeUpOptions);
 TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and 
 MIME headers. If the HTTP method in the HTTP header is not GET, and a error 
 will be reported.
 The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS 
 or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will 
 be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet(). 
 For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error 
 code. Hopefully there is some existing precedent to follow.
 TSFetchResource() should be cancellable via the TSAction return value.
 I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we 
 eliminate this, I'd argue for a uint64_t flags parameter.

--
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-1054) TSFetchUrl takes an address but does the DNS lookup anyway

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1054:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

Moving out to 3.1.3 for now.

 TSFetchUrl takes an address but does the DNS lookup anyway
 --

 Key: TS-1054
 URL: https://issues.apache.org/jira/browse/TS-1054
 Project: Traffic Server
  Issue Type: Bug
  Components: Performance
Affects Versions: 3.0.2
Reporter: James Peach
Assignee: James Peach
Priority: Minor
 Fix For: 3.1.3


 TSFetchUrl() takes an IP address as one of its arguments, so the API client 
 has to resolve the hostname portion of any URL it wants to fetch. However 
 once you get into the HTTP state machine, the host gets resolved again. One 
 of these DNS queries is redundant for performance reasons. Additionally, the 
 plugin might have some special knowledge about which IP address to use that 
 the DNS resolver doesn't, in which case the result would be wrong.
 [Dec 14 20:36:29.414] Server {0x7fff7b5f9960} DIAG: (plugin) [1] http request 
 (90 of 90 bytes):
 GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
 accept: */*
 [Dec 14 20:36:29.415] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [init] FetchSM 
 initialized for request with headers
 --
 GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
 accept: */*
 --
 [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [httpConnect] 
 calling httpconnect write
 [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Created 
 PluginVCCore at 0x102872c00, active 0x102872c38, passive 0x102872e10
 [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (http_seq) 
 HttpAccept:mainEvent] accepted connection
 [Dec 14 20:36:29.425] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] session 
 born, netvc 0x102872e10
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] using 
 accept inactivity timeout [120 seconds]
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] Starting 
 transaction 1 using sm [0]
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 do_io_read for 0 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 do_io_read for -1 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 do_io_read for -1 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 do_io_write for 90 bytes
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Passive: 
 Received event 1
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side; act_on 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 closed? 0 shutdown? 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Active: 
 Received event 1
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_read_side
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_read_side; act_on 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 closed? 0 shutdown? 0
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_write_side
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_write_side; act_on 90
 [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active: 
 process_write_side; added 90
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM) 
 [fetch_handler] calling fetch_plugin
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM) 
 [process_fetch_write] calling process write
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side; act_on 90
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 process_read_side; added 90
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] 
 [HttpSM::main_handler, VC_EVENT_READ_READY]
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] 
 [HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] done parsing 
 client request header
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive: 
 reenable Read
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) START 
 HttpTransact::ModifyRequest
 [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) 
 [ink_cluster_time] local: 1323923789, highest_delta: 0, cluster: 1323923789
 [Dec 14 20:36:29.437] 

[jira] [Updated] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1073:
--

Fix Version/s: (was: 3.1.3)
   3.1.2

 no_dns_just_forward_to_parent configuration parameter is ignored/not used.
 --

 Key: TS-1073
 URL: https://issues.apache.org/jira/browse/TS-1073
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS
Affects Versions: 3.0.2
 Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
 Fix For: 3.1.2

 Attachments: TS-1073.patch


 I have two instances of trafficserver configured, one instance is configured 
 to use the second instance as a parent proxy using the following parameters 
 from the records.config:
 CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
 CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
 The parent config looks like this:
 dest_domain=.  parent=parent:8080  round_robin=false
 The no_dns_just_forward_to_parent is not used in the code and as a result dns 
 lookups are being performed in the child instance.
 The following code changes seem to fix this:
 proxy/http/HttpSM.cc
 @@ -6406,11 +6405,20 @@
  t_state.dns_info.lookup_success = true;
  call_transact_and_set_next_state(NULL);
  break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED  
 t_state.dns_info.lookup_success) {
 // Already set, and we don't have a parent proxy to lookup
 ink_assert(t_state.host_db_info.ip());
 Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup, 
 provided by plugin);
 call_transact_and_set_next_state(NULL);
 break;
 +  } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER 
 
 + t_state.http_config_param-no_dns_forward_to_parent){
 +
 +if(t_state.cop_test_page) {
 +t_state.host_db_info.ip() 
 =t_state.state_machine-ua_session-get_netvc()-get_local_ip();
 +}
 +
 +t_state.dns_info.lookup_success = true;
 +call_transact_and_set_next_state(NULL);
 +break;
}
  
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
 to avoid reverse ns lookups
 /proxy/http/HttpTransact.cc
 @@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9' 
   s-dns_info.lookup_name[0] = '0' 
   //(s-state_machine-authAdapter.needs_rev_dns() ||
 - ( host_rule_in_CacheControlTable() || 
 s-parent_params-ParentTable-hostMatch)) {
 + ( host_rule_in_CacheControlTable() || 
 s-parent_params-ParentTable-hostMatch) 
 + !s-http_config_param-no_dns_forward_to_parent) {
  // note, broken logic: ACC fudges the OR stmt to always be true,
  // 'AuthHttpAdapter' should do the rev-dns if needed, not here .
  TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
 I would like to have these changes applied to the repository if they look ok.
 I also created an empty resolv.conf and pointed ats to the empty file:
 CONFIG proxy.config.dns.resolv_conf STRING 
 /usr/local/etc/trafficserver/resolv.conf
 When these changes are applied the child instance no longer attempts to 
 perform dns lookups for the
 http requests that it receives. If they are not applied and the dns lookup it 
 slow or unreliable on the
 child then the http requests are blocked by the dns lookup within the child 
 trafficserver instance.

--
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-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1091:
--

Fix Version/s: 3.1.2
 Assignee: Leif Hedstrom

 `./configure CFLAGS=-w` causes configure script to wrongly guess style of 
 `gethostbyname_r` on OS X (and probably other BSDs)
 -

 Key: TS-1091
 URL: https://issues.apache.org/jira/browse/TS-1091
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Affects Versions: 3.0.2
 Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Assignee: Leif Hedstrom
Priority: Minor
  Labels: autoconf, build, configure
 Fix For: 3.1.2

   Original Estimate: 10m
  Remaining Estimate: 10m

 {code}
 marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini 
 | grep 'System Version'
   System Version: Mac OS X 10.6.8 (10K549)
 marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
 ...
 checking style of gethostbyname_r routine... glibc2
 checking 3rd argument to the gethostbyname_r routines... hostent_data
 configure: Build using CC=gcc
 configure: Build using CXX=g++
 configure: Build using CPP=gcc -E
 configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3 
 -feliminate-unused-debug-symbols -fno-strict-aliasing
 ...
 marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
 gethostbyname_r_glibc2 = 1
 gethostbyname_r_hostent_data = 1
 marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
 ...
 ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int, 
 ink_gethostbyaddr_r_data*)':
 ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7' 
 to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int, 
 int*)'
 make[3]: *** [ink_inet.lo] Error 1
 make[2]: *** [all] Error 2
 make[1]: *** [all-recursive] Error 1
 make: *** [all-recursive] Error 1
 {code}
 Arguably, people should never run configure with CFLAGS=-w and this might 
 seem stupid and something that should never happen, but it turns out that 
 Homebrew (http://mxcl.github.com/homebrew/) does this by default 
 (https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while 
 writing a Homebrew formula for Traffic Server 
 (https://github.com/mxcl/homebrew/pull/9513). After discovering that this was 
 causing problems, I modified my formula to tell Homebrew not to do this and 
 all is well, but I thought it would be interesting to make Traffic Server 
 resistant to this as well.
 I first tried to enable warnings by trying to find a gcc #pragma that could 
 go in the conftest.c code 
 (http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising 
 but I could not find one that worked), but I could not find any #pragma that 
 seemed to do this.
 I ended up making a small change to `build/common.m4` that strips -w out of 
 CFLAGS using `sed`.
 {code}
 --- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
 +++ build/common.m4   2012-01-22 22:48:14.0 -0800
 @@ -177,6 +177,7 @@
   if test $ac_cv_prog_gcc = yes; then
 CFLAGS=$CFLAGS -Werror
   fi
 + CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 
 's/ -w / /')
   AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
 {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-1085) traffic_shell enable command doesn't work

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1085:
--

Fix Version/s: 3.1.3
 Assignee: James Peach

Moving out to 3.1.3, move back to 3.1.2 if you'll get this done this week.

 traffic_shell enable command doesn't work
 -

 Key: TS-1085
 URL: https://issues.apache.org/jira/browse/TS-1085
 Project: Traffic Server
  Issue Type: Bug
  Components: Management
Reporter: James Peach
Assignee: James Peach
 Fix For: 3.1.3


 Let's try this as root:
 blacko:trafficserver.git jpeach$ sudo /opt/ats/bin/traffic_shell
 Successfully Initialized MgmtAPI in /opt/ats/var/trafficserver 
 % trafficserver enable
 Already Enabled
 trafficserver exit
 Ok, to let's try as non-root:
 blacko:trafficserver.git jpeach$ /opt/ats/bin/traffic_shell
 [connect] ERROR (main_socket_fd 3): Permission denied
 TSInit 5: Failed to initialize MgmtAPI in /opt/ats/var/trafficserver
 [connect] ERROR (main_socket_fd 3): Permission denied
 % trafficserver enable
 FATAL: ConfigCmd.cc:137: failed assert `enable_restricted_commands`
 /opt/ats/bin/traffic_shell - STACK TRACE: 
 0   libtsutil.3.dylib   0x00010cec8b8b ink_fatal_va + 283
 1   libtsutil.3.dylib   0x00010cec8e94 ink_fatal + 356
 2   libtsutil.3.dylib   0x00010cec66ff _ink_assert + 271
 3   traffic_shell   0x00010ce253ab 
 _Z10Cmd_EnablePvP10Tcl_InterpiPPKc + 395
 4   Tcl 0x00010cf34261 
 TclInvokeStringCommand + 121
 5   Tcl 0x00010cf360b7 
 Tcl_GetMathFuncInfo + 2533
 6   Tcl 0x00010cf36d14 
 Tcl_GetMathFuncInfo + 5698
 7   Tcl 0x00010cf370d2 Tcl_Eval + 42
 So either enable does nothing or it crashes. Seems like we should fix or 
 remove 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] [Updated] (TS-1024) remap_required 0 not functioning in revproxy mode

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1024:
--

Fix Version/s: (was: 3.1.3)
   sometime

Moving this out to to later for now.

So, the issue here is that enabling reverse proxy sort of interferes with 
the parent proxy behavior here. If you disable reverse proxy (non-intuitive), 
and make sure that all requests are proxied to a parent proxy, I think it 
should work. The thing is, enabling reverse proxy currently implies that some 
sort of mapping should be done. So, in a pure parent proxy setup, you want

{code}
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
CONFIG proxy.config.reverse_proxy.enabled INT 0
CONFIG proxy.config.url_remap.remap_required INT 0
{code}

And then, you shouldn't need anything at all in remap.config (it's never 
consulted since reverse_proxy is disabled).

You have to be pretty careful in this setup, and assure that you parent proxy 
every request (otherwise, since remap isn't required, you could become an open 
proxy). We have sort of overloaded too much semantics into these two 
configuration options, hence, we might want to revisit it later (and redo it 
completely). The way I tend to see it is that requiring (and configuring) remap 
also acts as a whitelist of what requests should be proxied.

Let me know what you think.


 remap_required 0 not functioning in revproxy mode
 -

 Key: TS-1024
 URL: https://issues.apache.org/jira/browse/TS-1024
 Project: Traffic Server
  Issue Type: Bug
  Components: Remap API
Affects Versions: 3.0.2
Reporter: Greg Dallavalle
Assignee: Leif Hedstrom
Priority: Minor
  Labels: parent, remap_required
 Fix For: sometime


 with
 [records.config]
 proxy.config.url_remap.remap_required INT 0
 proxy.config.http.parent_proxy_routing_enable INT 1
 proxy.config.http.no_dns_just_forward_to_parent INT 1
 ATS still requires a remap URL to be used.  The way I worked around this was 
 to have remapped URLs to themselves:
 [remap.config]
 map http://example.com http://example.com
 map http://sub.example.com http://sub.example.com
 With those settings all requests are passed through to my origin, or parent 
 cache servers.  The pass to the parent cache did not work in 3.0.1.  I had 
 to build from the 3.0.x branch for this to function.
 [parent.config]
 dest_domain=.  parent=1.2.3.4:80; 4.5.6.7:80  round_robin=strict
 I think this is convoluted given my fairly common setup of two reverse 
 proxies caching/load balancing round robin to a few origin servers.  I guess 
 the only bug here is that the remap_required parameter is not functioning 
 as well as it could be.  I hope for improvement in the way this setup is 
 handled.

--
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-524) Have a single directive for HTTP ports

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-524:
-

Fix Version/s: (was: 3.1.4)

 Have a single directive for HTTP ports
 --

 Key: TS-524
 URL: https://issues.apache.org/jira/browse/TS-524
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration
Affects Versions: 3.0.0
 Environment: Any
Reporter: Marcus Clyne
Priority: Trivial

 Why have both
 proxy.config.http.server_port
 and
 proxy.config.http.server_other_ports
 as config options?  Unless there is a good reason to have to options, it 
 would probably be better to have a single config option.
 See also https://issues.apache.org/jira/browse/TS-523

--
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-523) [GSoC2011] Allow the use of multiple SSL ports

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-523:
-

Fix Version/s: (was: 3.1.3)

 [GSoC2011] Allow the use of multiple SSL ports
 --

 Key: TS-523
 URL: https://issues.apache.org/jira/browse/TS-523
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration, SSL
Affects Versions: 2.1.3
Reporter: Marcus Clyne
Priority: Minor
  Labels: gsoc2011, ssl

 Currently proxy.config.ssl.server_port allows only one SSL port to be 
 specified, and it appears that it is not possible to specify multiple ports 
 for SSL like proxy.config.http.server_other_ports.
 It would make sense to have a single directive as a string for all SSL ports, 
 rather than have two config options like HTTP ports (a separate ticket has 
 been posted for that - see https://issues.apache.org/jira/browse/TS-524).

--
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-448) Provide the ability to bind to more than one interface

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-448:
-

Fix Version/s: (was: 3.1.3)

 Provide the ability to bind to more than one interface
 --

 Key: TS-448
 URL: https://issues.apache.org/jira/browse/TS-448
 Project: Traffic Server
  Issue Type: Improvement
  Components: Network
Affects Versions: 2.1.0
Reporter: Shaun McGinnity
Priority: Minor

 If I am running Traffic Server on a machine with multiple interfaces I would 
 like to able to bind to a subset of those interfaces.
  
 I can bind to all or one using proxy.local.incoming_ip_to_bind but can't 
 bind to more than one, but not all.
 It would also be useful to be able to specify different listening ports per 
 interface.

--
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-1061) TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter (int *bytes) from the prototype in ./proxy/api/ts/ts.h. The extra parameter needs to be removed as

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1061:
--

Fix Version/s: (was: 3.1.1)
   3.1.2
 Assignee: Leif Hedstrom

I think this slipped under the radar, due to the old fix version (3.1.1 was 
released a while ago).

 TSHttpTxnServerReqHdrBytesGet in ./proxy/InkAPI.cc has an extra parameter 
 (int *bytes) from the prototype in ./proxy/api/ts/ts.h.  The extra parameter 
 needs to be removed as it is not used.
 -

 Key: TS-1061
 URL: https://issues.apache.org/jira/browse/TS-1061
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 3.1.1, 3.0.1
 Environment: Redhat Linux but it is not environment specific
Reporter: Alistair Stevenson
Assignee: Leif Hedstrom
Priority: Minor
  Labels: api-change
 Fix For: 3.1.2

   Original Estimate: 1h
  Remaining Estimate: 1h

 The definitions are:
 ./proxy/InkAPI.cc:TSHttpTxnServerReqHdrBytesGet(TSHttpTxn txnp, int *bytes)
 ./proxy/api/ts/ts.h.in:  tsapi int TSHttpTxnServerReqHdrBytesGet(TSHttpTxn 
 txnp);
 The int * bytes parameter is not used and means that the function does not 
 resolve and so cannot be used.

--
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-1094) TS hangs after repeated requests from the same kept-alive connection

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1094:
--

Fix Version/s: 3.1.3

Heh, that's one hell of a bug, 275 bytes exactly, eh?

 TS hangs after repeated requests from the same kept-alive connection
 

 Key: TS-1094
 URL: https://issues.apache.org/jira/browse/TS-1094
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.1.0
 Environment: Oracle Enterprise Linux 5.5 64-bit
Reporter: Wilson Ho
Priority: Blocker
 Fix For: 3.1.3


 When a client submits multiple requests while re-using the same keep-alived 
 connection, TS hangs.  Usually, the client eventually times out, and at that 
 point TS will be waken up and forwards the request to the original server.  
 But by then it's too late and the client already closed connection.
 In real life traffic, this bug is very hard to reproduce.  But here is an 
 artificial test case.
 First, make sure client-side keep alive is on.  My test case uses HTTP (port 
 80) GET.
 Second, make sure the total header size of the requests is exactly 275 bytes, 
 including the carriage returns and line feeds.  One byte more or less would 
 fail to reproduce the bug.
 Third, repeatedly submit the same request through this keep-alived 
 connection.  At exactly the 283rd iteration, TS hangs.  Note that if the 
 client opens a new connection every time, TS works fine.
 There is a second test case, where the header size is exactly 283 bytes, and 
 TS hangs at exactly the 275th iteration.  (Does 275 x 283 mean something?)
 These magic numbers seem to suggest a memory buffer size (or allocation) 
 problem.  I speculate that headers from repeated requests are placed in a 
 buffer (or a circular buffer?), and when the total hits a particular size, 
 some boundary conditions must have be violated and resulted in memory 
 corruption.
 In real life traffic, each request typically has slightly different header 
 size, so it is really hard to hit this bug.  I suspect there is a +/- 1 
 calculation error in some buffer.
 BTW, turning on/off caching does not make any difference.  

--
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-1102) Cleanup obsolete debugging code

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1102:
--

Fix Version/s: 3.1.2

 Cleanup obsolete debugging code
 ---

 Key: TS-1102
 URL: https://issues.apache.org/jira/browse/TS-1102
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Logging, Performance
Affects Versions: 3.0.2
 Environment: Any
Reporter: Uri Shachar
Assignee: Leif Hedstrom
Priority: Minor
 Fix For: 3.1.2

 Attachments: diags_cleanup.patch, remove_prefix_arg.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 
 for all compilation environments, and it includes variadic argument macro 
 support with ##_VA_ARGS_ that deletes the final comma if no arguments are 
 provided.
 Removing the added layer should also improve performance when high volume 
 debugging is turned on.

--
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-1102) Cleanup obsolete debugging code

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1102:
--

Fix Version/s: (was: 3.1.2)
   3.1.3

 Cleanup obsolete debugging code
 ---

 Key: TS-1102
 URL: https://issues.apache.org/jira/browse/TS-1102
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Logging, Performance
Affects Versions: 3.0.2
 Environment: Any
Reporter: Uri Shachar
Assignee: Leif Hedstrom
Priority: Minor
 Fix For: 3.1.3

 Attachments: diags_cleanup.patch, remove_prefix_arg.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 The current Diags.h D/EClosure mechanism is obsolete. ATS requires gcc = 4.1 
 for all compilation environments, and it includes variadic argument macro 
 support with ##_VA_ARGS_ that deletes the final comma if no arguments are 
 provided.
 Removing the added layer should also improve performance when high volume 
 debugging is turned on.

--
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-1079) Add an API function to turn debugging on for specific transactions/sessions

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1079:
--

Fix Version/s: 3.1.4

 Add an API function to turn debugging on for specific transactions/sessions
 ---

 Key: TS-1079
 URL: https://issues.apache.org/jira/browse/TS-1079
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core, HTTP
Reporter: Uri Shachar
Priority: Minor
 Fix For: 3.1.4

 Attachments: debug_specific.patch

   Original Estimate: 72h
  Remaining Estimate: 72h

   When attempting to troubleshoot issues on a production ATS system, it 
 is often impossible/difficult to turn on any of the 'high-volume' debug tags 
 like http due to the performance impact.
  
 This enhancement allows a plugin to set a debug flag for a specific txn/ssn, 
 and replaces some of the internal Debug calls with a new function that checks 
 if the flag is turned on, and outputs the debug line regardless of the tag if 
 it is (The diags enable/disable flag is still taken into account).
 The API will also have TSDebugSpecific in order to allow plugins to use the 
 same functionality.
 In addition, we might consider adding an internal config file (remap-like) to 
 allow turning this flag on without plugin intervention.
  

--
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-1090) Configuration and plugin support for SO_MARK (on supporting platforms)

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1090:
--

Fix Version/s: 3.1.3
 Assignee: B Wyatt

 Configuration and plugin support for SO_MARK (on supporting platforms)
 --

 Key: TS-1090
 URL: https://issues.apache.org/jira/browse/TS-1090
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP, Network, TS API
Reporter: B Wyatt
Assignee: B Wyatt
 Fix For: 3.1.3

 Attachments: so_mark.patch


 SO_MARK allows for all packets sent out via a given socket to be pre-marked 
 (similar to the -j MARK target in iptables, or the fwmark semantic in ip 
 rules).  This feature allows configuration to dictate SO_MARKs for accepting 
 sockets, cluster sockets and origin server sockets independently.  
 Additionally, plugins and internal systems can set per-transaction SO_MARKS 
 for outgoing packets. 

--
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-1087) TSHttpTxnOutgoingAddrSet forward declaration does not match implementation

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1087:
--

Fix Version/s: 3.1.3
 Assignee: B Wyatt

 TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
 --

 Key: TS-1087
 URL: https://issues.apache.org/jira/browse/TS-1087
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.1.0
Reporter: B Wyatt
Assignee: B Wyatt
Priority: Trivial
 Fix For: 3.1.3

 Attachments: txn-outgoing-addr.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

 ts.h.in lists the following declaration:
 {code}TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct sockaddr 
 const* addr);{code}
 However, the current implementation has this function sig:
 {code}tsapi TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct 
 sockaddr const* addr, socklen_t addrlen);{code}
 Trafficserver is unable to load plugins which use this function due to the 
 unresolved symbol.

--
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-1114) Crash report: HttpTransactCache::SelectFromAlternates

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1114:
--

Fix Version/s: 3.1.3

 Crash report: HttpTransactCache::SelectFromAlternates
 -

 Key: TS-1114
 URL: https://issues.apache.org/jira/browse/TS-1114
 Project: Traffic Server
  Issue Type: Bug
Reporter: Zhao Yongming
 Fix For: 3.1.3


 it may or may not be the upstream issue, let us open it for tracking.
 {code}
 #0  0x0053075e in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0, 
 http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
 1375((int32_t *)  val)[0] = m_alt-m_object_key[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-1103) Traffic Server ESI plugin issues

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1103:
--

Fix Version/s: 3.1.3

Any volunteers to review / commit this? If not, assign it to me.

 Traffic Server ESI plugin issues
 

 Key: TS-1103
 URL: https://issues.apache.org/jira/browse/TS-1103
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: sometime
 Environment: Newest trunk.
Reporter: Kevin Fox
 Fix For: 3.1.3

 Attachments: esi.patch


 Patch to fix:
  * Makefile fix to add missing files.
  * Change return code checking to match whats trunk trafficserver.
  * Include missing header files.
  * Fix c++ namespace issues.
  * Work around strange name mangling/linking issue.
  * Force the assumption that the cached data is RAW_ESI, not PACKED_ESI.
 Things wouldn't work without it.
  * Comment out a block of code that looked to be incorrectly handling
 EOF.
 After this, simply loading the plugin and setting response header X-ESI
 in apache httpd seems to work.
 A few further bugs I have bumped into that aren't addressed in this
 patch:
  * It doesn't seem to parse gzip like it looks like it should. To work
 around, I had to disable it in apache httpd with RewriteRule . -
 [E=no-gzip:1]
  * If the client requests gzip, the ESI processor will gzip the result.
 It works in firefox but is invalid in chrome. Pulling a dump with curl
 and running it through gzip --list shows it has the correct uncompressed
 size and compressed size. using zcat shows the correct data but has the
 warning: invalid compressed data--length error. As far as I read the
 gzip spec though, the raw binary file looks valid to me. Not sure what
 this is. This can probably be simply disabled for now though.
 * esi:include is slightly broken. You get all the data back properly but
 sometimes the headers are sent prematurely with a Content-Length of
 2**31-1. This causes clients to timeout and fail. I'm currently unsure
 how to fix this.
 I've tried a few of the more advanced esi features, including ensuring
 cookies make it back to the origin server and things seem to work good.
 So, once the above bugs are figured out (particularly the include one),
 I think it will be in pretty good shape.

--
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-1108) Allow to clear a particular cache volume

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1108:
--

Fix Version/s: sometime

 Allow to clear a particular cache volume
 --

 Key: TS-1108
 URL: https://issues.apache.org/jira/browse/TS-1108
 Project: Traffic Server
  Issue Type: New Feature
  Components: Cache
Reporter: Leif Hedstrom
 Fix For: sometime


 Today, you can clear the entire cache (either at startup, or via e.g. 
 -Cclear_cache). This wipes the entire cache. For someone hosting a small 
 number of sites, it might be reasonable to partition the cache (using 
 volume.config and hosting.config), such that each site gets a fraction of the 
 cache. In such a setup, it would also be reasonable (and usable) to be able 
 to clear just a single volume (e..g -Cclear_cache_volume 1   or some such).
 Thoughts?

--
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-1109) stack dump may crash too

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1109:
--

Fix Version/s: 3.1.3

 stack dump may crash too
 

 Key: TS-1109
 URL: https://issues.apache.org/jira/browse/TS-1109
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.1.2
Reporter: Zhao Yongming
Assignee: weijin
  Labels: crash
 Fix For: 3.1.3


 the codes doing stack dump may crash, in this case you will not able to get a 
 core file, that will hide most of the rare 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-1116) Fix build issues with clang (particularly on OSX)

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1116:
--

Attachment: TS-1116.diff

This fixes the build problems with clang. Alan, is this the right solution?

 Fix build issues with clang (particularly on OSX)
 -

 Key: TS-1116
 URL: https://issues.apache.org/jira/browse/TS-1116
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 3.1.3

 Attachments: TS-1116.diff


 We should get it to compile with clang again, specially since on OSX, clang 
 is the 'future'.

--
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-1121) --disable-diags configuration option does not do anything

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1121:
--

Fix Version/s: 3.1.3

 --disable-diags configuration option does not do anything
 -

 Key: TS-1121
 URL: https://issues.apache.org/jira/browse/TS-1121
 Project: Traffic Server
  Issue Type: Bug
  Components: Build, Core
Affects Versions: 3.0.3
 Environment: any
Reporter: Uri Shachar
Priority: Minor
 Fix For: 3.1.3

   Original Estimate: 2h
  Remaining Estimate: 2h

 The --disable-diags flag sets TS_USE_DIAGS to 0 but Diags.h tests if it is 
 defined or 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-1075) Port range bottleneck in transparent proxy mode

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1075:
--

Fix Version/s: 3.1.3
 Assignee: B Wyatt

Bart, putting this on you, can you take a look please?

 Port range bottleneck in transparent proxy mode
 ---

 Key: TS-1075
 URL: https://issues.apache.org/jira/browse/TS-1075
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.1
 Environment: Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support
 ATS compiled as: ./configure --enable-tproxy 
Reporter: Danny Shporer
Assignee: B Wyatt
 Fix For: 3.1.3

 Attachments: ports.patch


 The Linux TPROXY stack only takes into account the local addresses when using 
 dynamic bind (bind without specifying a specific port). This limits the port 
 range to only the local range (around 30K by default and can be extended to 
 around 64K) - this together with the TIME-WAIT Linux method of releasing 
 ports causes a bottleneck).
 One symptom of this is that traffic_cop cannot open a connection to the 
 server to monitor it (it gets error 99 - address already in use) and kills 
 it. 
 Another issue is when opening the connection to 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-1127) Wrong returned value of incoming port address

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1127:
--

Fix Version/s: (was: 3.1.4)
   3.1.3

amc, can you take a look at this?

 Wrong returned value of incoming port address
 -

 Key: TS-1127
 URL: https://issues.apache.org/jira/browse/TS-1127
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.1.2
Reporter: Yakov Kopel
 Fix For: 3.1.3

 Attachments: fix.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

 The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 
 2011 (TS-926) and it returns another value.
 in the old version it returned the incoming port of the TS(the port which the 
 client connected to the TS).
 in the new version the returned value is the sending port of the user.
 The different is in the line:
   -  return sm-t_state.client_info.port;
   +  return ink_inet_get_port(sm-t_state.client_info.addr);
 The assignment of those two members (port, addr) are in the HttpSM.cc file
   ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr());
   t_state.client_info.port = netvc-get_local_port();
   
 The old code gave the right answer from the port member,  and the new one 
 gives us wrong answer from the remote address.
 I attached a patch to fix this returned value.

--
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-1121) --disable-diags configuration option does not do anything

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1121:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 --disable-diags configuration option does not do anything
 -

 Key: TS-1121
 URL: https://issues.apache.org/jira/browse/TS-1121
 Project: Traffic Server
  Issue Type: Bug
  Components: Build, Core
Affects Versions: 3.0.3
 Environment: any
Reporter: Uri Shachar
Priority: Minor
 Fix For: 3.1.4

   Original Estimate: 2h
  Remaining Estimate: 2h

 The --disable-diags flag sets TS_USE_DIAGS to 0 but Diags.h tests if it is 
 defined or 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-1067) Remove unused config (and code) for bandwidth management

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1067:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 Remove unused config (and code) for bandwidth management
 

 Key: TS-1067
 URL: https://issues.apache.org/jira/browse/TS-1067
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cleanup
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
 Fix For: 3.1.4


 There's a configuration file, and code, related to bandwidth management for 
 the old UDP based streaming media protocols, that were part of the core (it's 
 long since gone). We should remove this for now, and possibly (for future 
 plugins) add APIs appropriate for 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] [Updated] (TS-1002) log unmapped HOST when pristine_host_hdr disabled

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1002:
--

Issue Type: New Feature  (was: Wish)

Can this bug be closed ?

 log unmapped HOST when pristine_host_hdr disabled
 -

 Key: TS-1002
 URL: https://issues.apache.org/jira/browse/TS-1002
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
 Fix For: 3.1.3

 Attachments: TS-1002.patch


 I want to log user request's Host in http header before remap. I write 
 logs_xml.config, like:  %{Host}cqh
 When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the 
 right Host which is not rewritten.
 When disable the config, I always get the rewritten/mapped Host which is 
 not what I need.
 logs_xml reference: 
 http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912

--
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-1113) In case of caching smaller than 1k size of file, It shoud be increase concurrent users.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1113:
--

Fix Version/s: (was: 3.2.0)
   3.3.0

I'm moving this to 3.3.0, but can you please provide more information what 
exactly you are are suggesting?

 In case of  caching smaller than 1k size of file,  It shoud be increase 
 concurrent users.
 -

 Key: TS-1113
 URL: https://issues.apache.org/jira/browse/TS-1113
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cache
Affects Versions: 3.1.1
Reporter: Eric Ahn
Priority: Minor
 Fix For: 3.3.0


 If there are a lot 1k sized objects, It's not good 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-844) ReadFromWriter fail in CacheRead.cc

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-844:
-

Fix Version/s: (was: sometime)

 ReadFromWriter fail in CacheRead.cc
 ---

 Key: TS-844
 URL: https://issues.apache.org/jira/browse/TS-844
 Project: Traffic Server
  Issue Type: Bug
Reporter: mohan_zl
Assignee: Zhao Yongming
 Attachments: TS-844-2.patch, TS-844.patch


 {code}
 #6  0x006ab4d7 in CacheVC::openReadChooseWriter (this=0x2aaaf81523d0, 
 event=1, e=0x0) at CacheRead.cc:320
 #7  0x006abdc9 in CacheVC::openReadFromWriter (this=0x2aaaf81523d0, 
 event=1, e=0x0) at CacheRead.cc:411
 #8  0x004d302f in Continuation::handleEvent (this=0x2aaaf81523d0, 
 event=1, data=0x0) at I_Continuation.h:146
 #9  0x006ae2b9 in Cache::open_read (this=0x2aaab0001c40, 
 cont=0x2aaab4472aa0, key=0x42100b10, request=0x2aaab44710f0, 
 params=0x2aaab4470928, type=CACHE_FRAG_TYPE_HTTP,
 hostname=0x2aab09581049 
 js.tongji.linezing.comicon1.gifjs.tongji.linezing.com�ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿ï¿½Þ­ï¿½ï¿½ï¿½...,
  host_len=22) at CacheRead.cc:228
 #10 0x0068da30 in Cache::open_read (this=0x2aaab0001c40, 
 cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0, 
 params=0x2aaab4470928,
 type=CACHE_FRAG_TYPE_HTTP) at P_CacheInternal.h:1068
 #11 0x0067d32f in CacheProcessor::open_read (this=0xf2c030, 
 cont=0x2aaab4472aa0, url=0x2aaab4471108, request=0x2aaab44710f0, 
 params=0x2aaab4470928, pin_in_cache=0,
 type=CACHE_FRAG_TYPE_HTTP) at Cache.cc:3011
 #12 0x0054e058 in HttpCacheSM::do_cache_open_read 
 (this=0x2aaab4472aa0) at HttpCacheSM.cc:220
 #13 0x0054e1a7 in HttpCacheSM::open_read (this=0x2aaab4472aa0, 
 url=0x2aaab4471108, hdr=0x2aaab44710f0, params=0x2aaab4470928, 
 pin_in_cache=0) at HttpCacheSM.cc:252
 #14 0x00568404 in HttpSM::do_cache_lookup_and_read 
 (this=0x2aaab4470830) at HttpSM.cc:3893
 #15 0x005734b5 in HttpSM::set_next_state (this=0x2aaab4470830) at 
 HttpSM.cc:6436
 #16 0x0056115a in HttpSM::call_transact_and_set_next_state 
 (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
 #17 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
 HttpSM.cc:1516
 #18 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
 event=0, data=0x0) at HttpSM.cc:1448
 #19 0x0056de77 in HttpSM::do_api_callout_internal 
 (this=0x2aaab4470830) at HttpSM.cc:4345
 #20 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
 HttpSM.cc:497
 #21 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
 HttpSM.cc:6362
 #22 0x0056115a in HttpSM::call_transact_and_set_next_state 
 (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
 #23 0x00572faf in HttpSM::set_next_state (this=0x2aaab4470830) at 
 HttpSM.cc:6378
 #24 0x0056115a in HttpSM::call_transact_and_set_next_state 
 (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
 #25 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
 HttpSM.cc:1516
 #26 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
 event=0, data=0x0) at HttpSM.cc:1448
 #27 0x0056de77 in HttpSM::do_api_callout_internal 
 (this=0x2aaab4470830) at HttpSM.cc:4345
 #28 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
 HttpSM.cc:497
 #29 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
 HttpSM.cc:6362
 #30 0x0056115a in HttpSM::call_transact_and_set_next_state 
 (this=0x2aaab4470830, f=0) at HttpSM.cc:6328
 #31 0x00574b78 in HttpSM::handle_api_return (this=0x2aaab4470830) at 
 HttpSM.cc:1516
 #32 0x0056dbe7 in HttpSM::state_api_callout (this=0x2aaab4470830, 
 event=0, data=0x0) at HttpSM.cc:1448
 #33 0x0056de77 in HttpSM::do_api_callout_internal 
 (this=0x2aaab4470830) at HttpSM.cc:4345
 #34 0x00578c89 in HttpSM::do_api_callout (this=0x2aaab4470830) at 
 HttpSM.cc:497
 #35 0x00572e93 in HttpSM::set_next_state (this=0x2aaab4470830) at 
 HttpSM.cc:6362
 #36 0x0056115a in HttpSM::call_transact_and_set_next_state 
 (this=0x2aaab4470830, f=0x59e52e 
 HttpTransact::ModifyRequest(HttpTransact::State*)) at HttpSM.cc:6328
 #37 0x0057490c in HttpSM::state_read_client_request_header 
 (this=0x2aaab4470830, event=100, data=0x2049f5e8) at HttpSM.cc:780
 #38 0x0056e49f in HttpSM::main_handler (this=0x2aaab4470830, 
 event=100, data=0x2049f5e8) at HttpSM.cc:2436
 

[jira] [Updated] (TS-821) memcached_remap plugin

[Leif Hedstrom (Updated) (JIRA)]

 [ 
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: sometime)
   3.1.3

 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: James Peach
Priority: Minor
 Fix For: 3.1.3

 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] [Updated] (TS-872) ATS 3.0 shows a http 502 error as a forward proxy server ！

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-872:
-

Fix Version/s: (was: sometime)

 ATS 3.0 shows a http 502 error as a forward proxy server ！
 --

 Key: TS-872
 URL: https://issues.apache.org/jira/browse/TS-872
 Project: Traffic Server
  Issue Type: Bug
  Components: DNS
Affects Versions: 3.0.0
 Environment: OS: Ubuntu 10.10, Traffic Server version:.3.0, Web 
 Browser：firefox 4.0.1，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 
 500G
Reporter: taoyunxing
  Labels: patch
   Original Estimate: 48h
  Remaining Estimate: 48h

 when I set up a forward proxy with ATS 3.0 and firefox 4.0.1 and start the 
 proxy server as a root, it shows me the following info:
 root@tyx-System-Product-Name:/usr/local/bin# ./traffic_server 
 [TrafficServer] using root directory '/usr/local'
 [Jul  6 08:56:36.765] {3077691088} STATUS: opened 
 /usr/local/var/log/trafficserver/diags.log
 [Jul  6 08:56:36.765] {3077691088} NOTE: updated diags config
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Config: 
 /usr/local/etc/trafficserver/ae_ua.config
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Opening config 
 /usr/local/etc/trafficserver/ae_ua.config
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
 [Jul  6 08:56:36.766] Server {3077691088} DEBUG: (http_aeua) 
 [init_http_aeua_filter] - Total loaded 0 REGEXP for 
 Accept-Enconding/User-Agent filtering
 [Jul  6 08:56:36.768] Server {3077691088} NOTE: cache clustering disabled
 [Jul  6 08:56:36.768] Server {3077691088} NOTE: clearing statistics
 [Jul  6 08:56:36.770] Server {3077691088} DEBUG: (dns) ink_dns_init: called 
 with init_called = 0
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (dns) 
 localhost=tyx-System-Product-Name
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (dns) Round-robin 
 nameservers = 0
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) Storage path is 
 /usr/local/var/trafficserver
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) Opening host.db, 
 size=20
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: configuration changed: 
 [hostdb.config] : reinitializing database
 [Jul  6 08:56:36.779] Server {3077691088} NOTE: reconfiguring host database
 [Jul  6 08:56:36.779] Server {3077691088} DEBUG: (hostdb) unable to unlink 
 /usr/local/etc/trafficserver/internal/hostdb.config
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: Configured store too 
 small, unable to reconfigure
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: unable to initialize 
 database (too little storage)
 : [hostdb.config] : disabling database
 You may need to 'reconfigure' your cache manually.  Please refer to
 the 'Configuration' chapter in the manual.
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: could not initialize host 
 database. Host database will be disabled
 [Jul  6 08:56:36.779] Server {3077691088} WARNING: bad hostdb or storage 
 configuration, hostdb disabled
 [Jul  6 08:56:36.780] Server {3077691088} NOTE: cache clustering disabled
 [Jul  6 08:56:36.834] Server {3057408880} WARNING: disk header different for 
 disk /usr/local/var/trafficserver/cache.db: clearing the disk
 [Jul  6 08:56:36.884] Server {3077691088} NOTE: logging initialized[7], 
 logging_mode = 3
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_init) 
 proxy.config.http.redirection_enabled = 0
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_init) 
 proxy.config.http.number_of_redirections = 1
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_init) 
 proxy.config.http.post_copy_size = 2048
 [Jul  6 08:56:36.887] Server {3077691088} DEBUG: (http_tproxy) Primary listen 
 socket transparency is off
 [Jul  6 08:56:36.890] Server {3077691088} NOTE: traffic server running
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) 
 DNSHandler::startEvent: on thread 0
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) open_con: opening 
 connection 8.8.8.8:53
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) random port = 42595
 [Jul  6 08:56:36.890] Server {3077691088} DEBUG: (dns) opening connection 
 8.8.8.8:53 SUCCEEDED for 0
 [Jul  6 08:56:36.918] Server {3058461552} NOTE: Clearing Disk: 
 /usr/local/var/trafficserver/cache.db
 [Jul  6 08:56:36.919] Server {3058461552} NOTE: clearing cache directory 
 '/usr/local/var/trafficserver/cache.db 16384:24575'
 [Jul  6 08:56:37.056] Server {3055303536} NOTE: cache enabled
 [Jul  6 08:56:45.632] Server {3002059632} DEBUG: (http_tproxy) Marking 
 accepted connect on b328c6e8 as not outbound transparent.
 [Jul  6 08:56:45.632] Server 

[jira] [Updated] (TS-1107) dynamically scale the number of net threads

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1107:
--

Affects Version/s: (was: 3.3.0)
Fix Version/s: 3.3.0

Probably a typo, but it's the fix version that should be 3.3.0 :).

 dynamically scale the number of net threads
 ---

 Key: TS-1107
 URL: https://issues.apache.org/jira/browse/TS-1107
 Project: Traffic Server
  Issue Type: New Feature
  Components: Core, Performance
Reporter: James Peach
Priority: Minor
 Fix For: 3.3.0


 The number of net threads is calculated once at startup, but we ought to 
 consider dynamically scaling the number of threads a runtime based on load.
 zwoop: right, that's what I meant (keep a counter of how many times epoll had 
 no events, and treat that as an idle thread)
 zwoop: probably a multiplier of some setting (thread_idle_seconds or some 
 such)
 zwoop: this would be a cool feature, if you have the time for it ;)
 zwoop: can keep the original calculations / settings as the upper limit I 
 think
 zwoop: (the calculations can also easily be configured in records.config, so 
 that people can modify that upper limit)
 zwoop: an ideal solution (backward compatible) would be to just add one new 
 setting, reap_idle_threads_seconds or some such, default to 0 (off). With 
 it not set, our normal logic applies. With it set, your stuff takes effect, 
 but cap it at whatever the other settings are.

--
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-827) TSMimeHdrFieldValueStringInsert() can use freed memory to edit headers

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-827:
-

Fix Version/s: 3.1.4

Reopening this, I think we have a better solution available for this soon.

 TSMimeHdrFieldValueStringInsert() can use freed memory to edit headers
 --

 Key: TS-827
 URL: https://issues.apache.org/jira/browse/TS-827
 Project: Traffic Server
  Issue Type: Bug
  Components: MIME
Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4
Reporter: William Bardwell
Assignee: Leif Hedstrom
 Fix For: 3.1.4, 3.1.0, 3.0.0

 Attachments: headers-prealloc.diff


 TSMimeHdrFieldValueStringInsert() and other TSMimeHdrFieldValue*() APIs can 
 use freed memory to edit headers
 due to calling HdrHeap::coalesce_str_heaps() from HdrHeap::allocate_str() from
 mime_field_value_insert_comma_val() and other mime_field_value_*comma_val() 
 functions while holding pointers
 into the HdrHeap.
 I have a hacky but functional patch for 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] [Updated] (TS-1127) Wrong returned value of incoming port address

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1127:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 Wrong returned value of incoming port address
 -

 Key: TS-1127
 URL: https://issues.apache.org/jira/browse/TS-1127
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.1.2
Reporter: Yakov Kopel
Assignee: Alan M. Carroll
 Fix For: 3.1.4

 Attachments: fix.patch

   Original Estimate: 1m
  Remaining Estimate: 1m

 The API TSHttpTxnClientIncomingPortGet has been changed in Wed Oct 5 19:14:07 
 2011 (TS-926) and it returns another value.
 in the old version it returned the incoming port of the TS(the port which the 
 client connected to the TS).
 in the new version the returned value is the sending port of the user.
 The different is in the line:
   -  return sm-t_state.client_info.port;
   +  return ink_inet_get_port(sm-t_state.client_info.addr);
 The assignment of those two members (port, addr) are in the HttpSM.cc file
   ink_inet_copy(t_state.client_info.addr, netvc-get_remote_addr());
   t_state.client_info.port = netvc-get_local_port();
   
 The old code gave the right answer from the port member,  and the new one 
 gives us wrong answer from the remote address.
 I attached a patch to fix this returned value.

--
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-1114) Crash report: HttpTransactCache::SelectFromAlternates

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1114:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 Crash report: HttpTransactCache::SelectFromAlternates
 -

 Key: TS-1114
 URL: https://issues.apache.org/jira/browse/TS-1114
 Project: Traffic Server
  Issue Type: Bug
Reporter: Zhao Yongming
Assignee: weijin
 Fix For: 3.1.4

 Attachments: cache_crash.diff


 it may or may not be the upstream issue, let us open it for tracking.
 {code}
 #0  0x0053075e in HttpTransactCache::SelectFromAlternates 
 (cache_vector=0x2aaab80ff500, client_request=0x2aaab80ff4c0, 
 http_config_params=0x2aaab547b800) at ../../proxy/hdrs/HTTP.h:1375
 1375((int32_t *)  val)[0] = m_alt-m_object_key[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-1130) ink_time_t is 64bit on x86_64

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1130:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 ink_time_t is 64bit on x86_64
 -

 Key: TS-1130
 URL: https://issues.apache.org/jira/browse/TS-1130
 Project: Traffic Server
  Issue Type: Sub-task
  Components: Core
Reporter: Zhao Yongming
Assignee: weijin
 Fix For: 3.1.4


 Weijin: paste your patch here, :D

--
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-1143) IpMap::fill fails to handle some edge cases.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1143:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 IpMap::fill fails to handle some edge cases.
 

 Key: TS-1143
 URL: https://issues.apache.org/jira/browse/TS-1143
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 3.1.2
Reporter: Alan M. Carroll
Assignee: Alan M. Carroll
Priority: Minor
 Fix For: 3.1.4


 Three related issues:
 1) Input ranges with a min value of zero can be mishandled due to wrap.
 2) Input ranges with a maximum value can be mishandled due to wrap.
 3) Fill sometimes fails to insert ranges between two existing ranges.

--
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-1075) Port range bottleneck in transparent proxy mode

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1075:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 Port range bottleneck in transparent proxy mode
 ---

 Key: TS-1075
 URL: https://issues.apache.org/jira/browse/TS-1075
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.0.1
 Environment: Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support
 ATS compiled as: ./configure --enable-tproxy 
Reporter: Danny Shporer
Assignee: B Wyatt
 Fix For: 3.1.4

 Attachments: ports.patch


 The Linux TPROXY stack only takes into account the local addresses when using 
 dynamic bind (bind without specifying a specific port). This limits the port 
 range to only the local range (around 30K by default and can be extended to 
 around 64K) - this together with the TIME-WAIT Linux method of releasing 
 ports causes a bottleneck).
 One symptom of this is that traffic_cop cannot open a connection to the 
 server to monitor it (it gets error 99 - address already in use) and kills 
 it. 
 Another issue is when opening the connection to 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-1140) Implement HTTP method filtering in ip_allow.config

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1140:
--

Fix Version/s: (was: 3.1.3)
   3.1.4

 Implement HTTP method filtering in ip_allow.config
 --

 Key: TS-1140
 URL: https://issues.apache.org/jira/browse/TS-1140
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP
Affects Versions: 3.1.3, 3.1.2
Reporter: Igor Brezac
Priority: Critical
 Fix For: 3.1.4

 Attachments: ts-1140-v2.diff, ts-1140.diff, ts.patch


 Implement HTTP method filtering in ip_allow.config (and deprecate 
 proxy.config.http.quick_filter.mask)

--
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-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1125:
--

Fix Version/s: 3.1.4

 POST's with Expect: 100-continue are slowed by delayed 100 response.
 

 Key: TS-1125
 URL: https://issues.apache.org/jira/browse/TS-1125
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.2
 Environment: TS 3.0.2 going to Apache 2.2 web server
Reporter: William Bardwell
Priority: Minor
 Fix For: 3.1.4


 Sending a post like:
 POST / HTTP/1.1
 Host: www.example.com
 Content-Length: 10
 Expect: 100-continue
 directly to the web server immediately sends back:
 HTTP/1.1 100 Continue
 And then when the post data is sent, a status 200 response comes back.
 But when going through ATS the HTTP/1.1 100 Continue is not sent 
 immediately, and instead is sent after the POST data has been received.  This 
 is legal, but it makes clients that are hoping for a 100 continue to wait a 
 little while hoping to get that, ATS should forward that response through 
 immediately.
 Note: I see curl using Expect: 100-continue with  1024 bytes of post data, 
 but web searching indicates that some Microsoft products also use 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-1161) insafe raw device in storage.config

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1161:
--

Fix Version/s: 3.1.4

 insafe raw device in storage.config
 ---

 Key: TS-1161
 URL: https://issues.apache.org/jira/browse/TS-1161
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Zhao Yongming
 Fix For: 3.1.4


 if you system is on /dev/sda and you put /dev/sda into storage.config, TS 
 will destroy the data on /dev/sda without any hesitate.
 this is proved to be true, please do not try, trust me.

--
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-1154) quick_filter on HEAD does not work

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1154:
--

Fix Version/s: 3.1.4

 quick_filter on HEAD does not work
 --

 Key: TS-1154
 URL: https://issues.apache.org/jira/browse/TS-1154
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Zhao Yongming
Assignee: weijin
 Fix For: 3.1.4

 Attachments: head_method.diff


 we take quick filter as a good solution for some security concern, but when I 
 set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that.
 Weijin have the patch in our tree: 
 https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd
 I will commit if no one complain in 2 days.

--
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-1119) fatal error when uploading gzip-transform plugin

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1119:
--

Fix Version/s: 3.1.4

 fatal error when uploading gzip-transform plugin
 

 Key: TS-1119
 URL: https://issues.apache.org/jira/browse/TS-1119
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 3.0.2
Reporter: angela asher
Priority: Blocker
 Fix For: 3.1.4

 Attachments: gzip-transform.diff


 getting the following error on traffic.out when running the traffic server 
 with gzip-transform plugin:
 [Feb 23 16:28:15.509] Server {47392853811680} DEBUG: (http) [13] calling 
 plugin on hook TS_HTTP_READ_RESPONSE_HDR_HOOK at hook 0x35BBEE0
 FATAL: InkAPI.cc:3036: failed assert `sdk_sanity_check_null_ptr((void*) 
 value_len_ptr) == TS_SUCCESS`
 /usr/local/bin/traffic_server - STACK TRACE: 
 /usr/local/lib/libtsutil.so.3(ink_fatal_va+0x9d)[0x2b1a7ecca37d]
 /usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2b1a7ecca4d8]
 /usr/local/lib/libtsutil.so.3(_ink_assert+0x85)[0x2b1a7ecc8af5]
 /usr/local/bin/traffic_server(TSMimeHdrFieldValueStringGet+0x124)[0x4a9144]
 /usr/local/libexec/trafficserver/gzip-transform.so(+0x1bde)[0x2b1a8b3c7bde]
 /usr/local/libexec/trafficserver/gzip-transform.so(+0x27c4)[0x2b1a8b3c87c4]
 /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52cfa5]
 /usr/local/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x420)[0x52f1c0]
 /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x530568]
 /usr/local/bin/traffic_server[0x681dcb]
 /usr/local/bin/traffic_server[0x6848f1]
 /usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67d402]
 /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6a9ce4]
 /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6aa673]
 /usr/local/bin/traffic_server(main+0x1128)[0x4c07e8]
 /lib64/libc.so.6(__libc_start_main+0xfd)[0x2b1a81092c5d]
 /usr/local/bin/traffic_server[0x47e0e9]
 [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: 
 [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6: 
 Aborted
 [Feb 23 16:28:15.512] Manager {140400187066336} ERROR:  (last system error 2: 
 No such file or directory)
 [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: [Alarms::signalAlarm] 
 Server Process was reset
 [Feb 23 16:28:15.512] Manager {140400187066336} ERROR:  (last system error 2: 
 No such file or directory)
 [Feb 23 16:28:16.522] Manager {140400187066336} NOTE: 
 [LocalManager::startProxy] Launching ts process
 [TrafficServer] using root directory '/usr/local'
 [Feb 23 16:28:16.527] Manager {140400187066336} NOTE: 
 [LocalManager::pollMgmtProcessServer] New process connecting fd '11'
 [Feb 23 16:28:16.527] Manager {140400187066336} NOTE: [Alarms::signalAlarm] 
 Server Process born
 [Feb 23 16:28:17.539] {47668265021920} STATUS: opened 
 /usr/local/var/log/trafficserver/diags.log
 [Feb 23 16:28:17.539] {47668265021920} NOTE: updated diags config
 [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Config: 
 /usr/local/etc/trafficserver/ae_ua.config
 [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Opening config 
 /usr/local/etc/trafficserver/ae_ua.config
 [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua) 
 [HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
 [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua) 
 [init_http_aeua_filter] - Total loaded 0 REGEXP for 
 Accept-Enconding/User-Agent filtering
 [Feb 23 16:28:17.542] Server {47668265021920} NOTE: cache clustering disabled
 [Feb 23 16:28:17.543] Server {47668265021920} DEBUG: (dns) ink_dns_init: 
 called with init_called = 0
 [Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns) 
 localhost=isk-vsrv227
 [Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns) Round-robin 
 nameservers = 0
 [Feb 23 16:28:17.547] Server {47668265021920} NOTE: cache clustering disabled
 [Feb 23 16:28:17.568] Server {47668265021920} NOTE: logging initialized[7], 
 logging_mode = 3
 [Feb 23 16:28:17.569] Server {47668265021920} NOTE: loading plugin 
 '/usr/local/libexec/trafficserver/gzip-transform.so'
 [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init) 
 proxy.config.http.redirection_enabled = 0
 [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init) 
 proxy.config.http.number_of_redirections = 1
 [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init) 
 proxy.config.http.post_copy_size = 2048
 [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_tproxy) Primary 
 listen socket transparency is off
 [Feb 23 16:28:17.573] Server {47668424926976} DEBUG: 

[jira] [Updated] (TS-1151) in some strange situation, cop will crash

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1151:
--

Fix Version/s: 3.1.4

 in some strange situation, cop will crash
 -

 Key: TS-1151
 URL: https://issues.apache.org/jira/browse/TS-1151
 Project: Traffic Server
  Issue Type: Bug
Reporter: Zhao Yongming
Assignee: Zhao Yongming
 Fix For: 3.1.4


 we get some strange crash, the manager  cop may die, we are not sure what 
 that is, but I'd like to start one Issue here if we have other same issue.
 here is the log in /var/log/messages
 {code}
 Mar 19 10:08:24 cache172.cn77 kernel:: [1553138.961401] [ET_NET 2][17949]: 
 segfault at 2aadf1387937 ip 003c5bc7bdbe sp 410f3188 error 4 in 
 libc-2.5.so[3c5bc0+14d000]
 Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL: 
  (last system error 104: Connection reset by peer)
 Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR: 
  (last system error 32: Broken pipe)
 Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: cop received child status 
 signal [17935 2816]
 Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: traffic_manager not 
 running, making sure traffic_server is dead
 Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: spawning traffic_manager
 Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: --- Manager 
 Starting ---
 Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: Manager Version: 
 Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar  9 2012 
 at 09:55:44)
 Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} STATUS: 
 opened /var/log/trafficserver/manager.log
 Mar 19 10:08:46 cache172.cn77 traffic_cop[17933]: (cli test) unable to 
 retrieve manager_binary
 Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: --- Server Starting 
 ---
 Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: Server Version: 
 Apache Traffic Server - traffic_server - 3.0.2 - (build # 299 on Mar  9 2012 
 at 09:56:00)
 Mar 19 10:09:00 cache172.cn77 traffic_server[2789]: {0x2b5a8ef03970} STATUS: 
 opened /var/log/trafficserver/diags.log
 Mar 19 10:14:02 cache172.cn77 kernel:: [1553476.364204] [ET_NET 0][2789]: 
 segfault at 2aab1fa99ce3 ip 003c5bc7bdbe sp 7fff39743fa8 error 4 in 
 libc-2.5.so[3c5bc0+14d000]
 Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:  
 (last system error 104: Connection reset by peer)
 Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:  
 (last system error 32: Broken pipe)
 {code}
 here is the message in traffic.out
 {code}
 Mar 19 10:11:06 cache162.cn77 kernel:: [2510081.212455] [ET_NET 3][319]: 
 segfault at 2aaae6e986bc ip 003f7f27bdbe sp 40be2188 error 4 in 
 libc-2.5.so[3f7f20+14d000]
 Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL: 
 [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
 Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:  
 (last system error 104: Connection reset by peer)
 Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR: 
 [LocalManager::sendMgmtMsgToProcesses] Error writing message
 Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:  
 (last system error 32: Broken pipe)
 Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: cop received child status 
 signal [305 2816]
 Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: traffic_manager not running, 
 making sure traffic_server is dead
 Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: spawning traffic_manager
 Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: --- Manager 
 Starting ---
 Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: Manager Version: 
 Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar  9 2012 
 at 09:55:44)
 Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} STATUS: 
 opened /var/log/trafficserver/manager.log
 Mar 19 10:11:23 cache162.cn77 traffic_cop[303]: (cli test) unable to retrieve 
 manager_binary
 Mar 19 10:11:39 cache162.cn77 traffic_server[1260]: NOTE: --- Server Starting 
 ---
 Mar 19 10:11:39 

[jira] [Updated] (TS-1152) http_ui error,when i get http://localhost/cache/

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1152:
--

Fix Version/s: 3.1.4

 http_ui error,when i get http://localhost/cache/
 

 Key: TS-1152
 URL: https://issues.apache.org/jira/browse/TS-1152
 Project: Traffic Server
  Issue Type: Bug
  Components: Web UI
Affects Versions: 3.0.4
 Environment: centos 6 x86_64
Reporter: bettydramit
 Fix For: 3.1.4


 When i enable http_ui  ，I got follow error (get http://xxx.xxx.xxx.xxx/cache/)
 [Mar 19 16:46:17.778] Manager {13989191624} ERROR: 
 [WebHttpHandleConnection] /favicon.ico not valid autoconf file
 [Mar 19 16:46:17.778] Manager {13989191624} ERROR:  (last system error 
 11: Resource temporarily unavailable)
 [Mar 19 16:46:19.089] Manager {13989191624} ERROR: 
 [WebHttpHandleConnection] /favicon.ico not valid autoconf file
 [Mar 19 16:46:19.090] Manager {13989191624} ERROR:  (last system error 
 11: Resource temporarily unavailable)
 [Mar 19 16:46:20.763] Manager {13989191624} ERROR: 
 [WebHttpHandleConnection] /favicon.ico not valid autoconf file
 [Mar 19 16:46:20.763] Manager {13989191624} ERROR:  (last system error 
 11: Resource temporarily unavailable)
 [Mar 19 16:58:21.906] Manager {13989191624} ERROR: 
 [WebHttpHandleConnection] /robots.txt not valid autoconf file
 [Mar 19 16:58:21.906] Manager {13989191624} ERROR:  (last system error 
 11: Resource temporarily unavailable)
 [Mar 19 17:01:43.703] Manager {13989191624} ERROR: 
 [WebHttpHandleConnection] /favicon.ico not valid autoconf file
 [Mar 19 17:01:43.703] Manager {13989191624} ERROR:  (last system error 
 11: Resource temporarily unavailable)

--
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-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1163:
--

Fix Version/s: 3.1.4

 Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on 
 linux
 --

 Key: TS-1163
 URL: https://issues.apache.org/jira/browse/TS-1163
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Reporter: B Wyatt
Assignee: B Wyatt
 Fix For: 3.1.4

 Attachments: blkgetsize64.bwyatt.patch


 Due to 32bit integers in both the trafficersever code and the ioctl used to 
 determine raw disk size, the number of sectors reported to the cache storage 
 system is bound to 0-0x.  If a disk has 512 byte sectors and is 
 larger than 2TB it will report (num_sectors % 0x) *  512 bytes 
 avaliable.

--
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-1162) UnixNetVConnection.cc assertion when accepting a TLS connection

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1162:
--

Fix Version/s: 3.1.4

 UnixNetVConnection.cc assertion when accepting a TLS connection
 ---

 Key: TS-1162
 URL: https://issues.apache.org/jira/browse/TS-1162
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 3.1.4
Reporter: James Peach
 Fix For: 3.1.4


 Trunk always crashes when accepting a TLS connection:
 FATAL: UnixNetVConnection.cc:801: failed assert `vio-mutex-thread_holding 
 == this_ethread()`
 /opt/ats/bin/traffic_server - STACK TRACE: 
 0   libtsutil.3.dylib   0x00010c3e7ee7 ink_fatal + 359
 1   libtsutil.3.dylib   0x00010c3e6e22 _ink_assert + 66
 2   traffic_server  0x00010b9e6d9a 
 _ZN18UnixNetVConnection11set_enabledEP3VIO + 90
 3   traffic_server  0x00010b9e681d 
 _ZN18UnixNetVConnection8reenableEP3VIO + 93
 4   traffic_server  0x00010b7bfcd6 _ZN3VIO8reenableEv 
 + 54
 5   traffic_server  0x00010b9e5cd9 
 _ZN18UnixNetVConnection10do_io_readEP12ContinuationxP9MIOBuffer + 297
 6   traffic_server  0x00010b792611 
 _ZN11VConnection5do_ioEiP12ContinuationxP9MIOBufferi + 129
 7   traffic_server  0x00010b9d6da9 
 _ZN21SSLNextProtocolAccept9mainEventEiPv + 329
 8   traffic_server  0x00010b792229 
 _ZN12Continuation11handleEventEiPv + 121
 9   traffic_server  0x00010b9e89bd 
 _ZN18UnixNetVConnection11acceptEventEiP5Event + 829
 10  traffic_server  0x00010b792229 
 _ZN12Continuation11handleEventEiPv + 121
 11  traffic_server  0x00010ba0905d 
 _ZN7EThread13process_eventEP5Eventi + 349
 12  traffic_server  0x00010ba09367 
 _ZN7EThread7executeEv + 215
 13  traffic_server  0x00010ba080ed 
 _ZL21spawn_thread_internalPv + 109
 14  libsystem_c.dylib   0x7fff8fcb78bf _pthread_start + 
 335
 15  libsystem_c.dylib   0x7fff8fcbab75 thread_start + 13
 [Mar 22 21:58:45.009] Manager {0x7fff79b01960} ERROR: 
 [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6: 
 Abort trap: 6

--
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-1132) Clean up usage of HDR_BUF_RONLY_HEAPS

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-1132:
--

Fix Version/s: (was: 3.1.4)
   sometime

This is partially fixed in TS-1150. Moving this out to sometime when we might 
need this feature. When we do, we should also make the header heap size 
configurable, and not static to 2kB

 Clean up usage of HDR_BUF_RONLY_HEAPS
 -

 Key: TS-1132
 URL: https://issues.apache.org/jira/browse/TS-1132
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: Leif Hedstrom
 Fix For: sometime


 We should clean up the usage of HDR_BUF_RONLY_HEAPS, and not assume it's 
 always 3. In addition, we should consider making this configurable, via 
 either records.config, or at least configure.ac.

--
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-61) multiple do_io_pread on a CacheVConnection

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-61:


Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 multiple do_io_pread on a CacheVConnection
 --

 Key: TS-61
 URL: https://issues.apache.org/jira/browse/TS-61
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cache
Affects Versions: 3.0.0
Reporter: John Plevyak
Assignee: John Plevyak
 Fix For: 3.3.0

 Attachments: pread-2.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 The current TS-46 patch includes do_io_pread support but allows only a single 
 do_io_pread.
 In order to efficiently support range requests with multiple ranges it would 
 be helpful to be able
 to do multiple do_io_pread's on a single open CacheVConnection.

--
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-904) when doing custom logging, it would be nice if we can set dedicate sampling rate for each rule

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-904:
-

Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 when doing custom logging, it would be nice if we can set dedicate sampling 
 rate for each rule
 --

 Key: TS-904
 URL: https://issues.apache.org/jira/browse/TS-904
 Project: Traffic Server
  Issue Type: New Feature
  Components: Logging
Affects Versions: 3.0.0
Reporter: Zhao Yongming
Priority: Minor
 Fix For: 3.3.0


 the sampling is a global config in logging, we want to get it custom-able.

--
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-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-871:
-

Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
 ---

 Key: TS-871
 URL: https://issues.apache.org/jira/browse/TS-871
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Leif Hedstrom
 Fix For: 3.3.0

 Attachments: TS-871.diff, ats_Thttp.debug.notime.txt, 
 ats_Thttp.debug.txt, revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, 
 serf_proxy.cap, serf_revproxy.cap, stats.diff


 When accessing a remote subversion repository via http or https with svn 1.7, 
 it will currently timeout:
 {noformat}
 igalic@tynix ~/src/asf % svn co 
 http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
 svn: E020014: Unable to connect to a repository at URL 
 'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
 svn: E020014: Unspecified error message: 504 Connection Timed Out
 1 igalic@tynix ~/src/asf %
 {noformat}
 I have started traffic_server -Thttp and captured the output, which I'm 
 attaching.
 There's also a capture from the network.

--
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-343) The cache lookup and add operation use different key in plugin

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-343:
-

Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 The cache lookup and add operation use different key in plugin
 --

 Key: TS-343
 URL: https://issues.apache.org/jira/browse/TS-343
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Affects Versions: 3.0.0
Reporter: Flier Lu
Priority: Critical
 Fix For: 3.3.0


 I'm developing a cache plugin base on the redis, 
 http://code.google.com/p/rediscache/
 The plugin could be loaded and hook the cache read/write operations
 [May  9 16:25:05.012] Server {3079476928} NOTE: loading plugin 
 'libexec/trafficserver/redis_cache.so'
 [May  9 16:25:05.014] Server {3079476928} DIAG: (cache_plugin) 
 [INKPluginInit] Starting redis cache plugin
 But the cache lookup and add operation use different key, it seems use the 
 url as lookup key
 [May  9 16:25:13.149] Server {3066555280} DEBUG: (cache_plugin) 
 [CacheProcessor::open_read] Cache hooks are set
 [May  9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin) 
 [NewCacheVC::alloc] new B33B1EE0
 [May  9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin) 
 [NewCacheVC::set_cache_http_hdr]
 [May  9 16:25:13.153] Server {3066555280} DIAG: (cache_plugin) [cache_read]
 [May  9 16:25:13.153] Server {3066555280} DEBUG: (cache_plugin) 
 [INKCacheKeyGet] vc get cache key
 [May  9 16:25:13.158] Server {3066555280} DIAG: (cache_plugin) cache hitted 
 for key: http://www.baidu.com/ w/ 0 bytes value
 [May  9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin) 
 [INKHttpCacheReenable] event id: 1133 data: 0 size: 0
 [May  9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin) 
 [INKHttpCacheReenable] cache_lookup_complete
 [May  9 16:25:13.158] Server {3066555280} DEBUG: (cache_plugin) 
 [INKHttpCacheReenable] open read failed
 but store the cache item with a random MD5 as key
 [May  9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin) 
 [NewCacheVC::handleWrite] event=1
 [May  9 16:25:13.334] Server {3079476928} DIAG: (cache_plugin) [cache_write]
 [May  9 16:25:13.334] Server {3079476928} DEBUG: (cache_plugin) 
 [INKCacheKeyGet] vc get cache key
 [May  9 16:25:13.346] Server {3079476928} DIAG: (cache_plugin) put 3571 bytes 
 value to redis w/ 16 bytes key: 0xb33b1fb0
 [May  9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin) 
 [INKHttpCacheReenable] event id: 1129 data: 0 size: 3571
 [May  9 16:25:13.346] Server {3079476928} DEBUG: (cache_plugin) 
 [INKHttpCacheReenable] cache_write
 I'm not sure whether it is a design issue or bug ? and the cache lookup 
 always has 0 size buffer ?

--
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-378) FIx the strict-aliasing rules warnings

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-378:
-

Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 FIx the strict-aliasing rules warnings
 --

 Key: TS-378
 URL: https://issues.apache.org/jira/browse/TS-378
 Project: Traffic Server
  Issue Type: Improvement
  Components: Cleanup
Affects Versions: 3.0.0
Reporter: Mladen Turk
Assignee: Mladen Turk
Priority: Minor
 Fix For: 3.3.0


 Currently the compile fails with -fstrict-aliasing.
 The reason is mostly using int pointers to read or write 64 bit numbers
 Eg. INK_MD5.cc has
 struct INK_MD5
 {
   uint64 b[2];
   uint32 word(int i)
   {
 uint32 *p = (uint32 *)  b[0];
 return p[i];
   }
  ...
 };
 Such things can be easily fixed and properly handled using unions
 (they are invented for that)
 struct INK_MD5
 {
   union {
  uint64 q[2];
  uint32 u[4];
  unsigned char b[16];
   } s;
   uint32 word(int i)
   {
 return s.w[i];
   }
  ...
 };

--
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-110) Improve regex remap to allow substitutions in path field

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-110:
-

Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 Improve regex remap to allow substitutions in path field
 

 Key: TS-110
 URL: https://issues.apache.org/jira/browse/TS-110
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Affects Versions: 3.0.0
Reporter: Manjesh Nilange
Priority: Minor
 Fix For: 3.3.0


 Currently, regex support covers only the host field of the remap rules. It'd 
 be nice to extend this to allow substitutions into the path field as well. 
 This will allow rules like:
 regex_map http://www.example-(.*).com/ http://real-example.com/$1

--
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-879) Seek on cached file

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-879:
-

Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 Seek on cached file
 ---

 Key: TS-879
 URL: https://issues.apache.org/jira/browse/TS-879
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache, TS API
Affects Versions: 3.0.0
Reporter: Nelson Pérez
  Labels: api-addition, cache, trafficserver
 Fix For: 3.3.0


 I want a custom written plugin to be able to seek to any point in a cached 
 file. According to John Plevyak 
 (http://www.mail-archive.com/dev@trafficserver.apache.org/msg02785.html) this 
 feature is new in the cache, but not yet available to the API. 

--
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-817) TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests

[Leif Hedstrom (Updated) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-817:
-

Fix Version/s: (was: 3.1.6)
   3.3.0

Moving out to v3.3.0, move back to 3.1.4 if this will be work on *soon*.

 TSFetchUrl/TSFetchPages does not work with HTTP/1.1 requests
 

 Key: TS-817
 URL: https://issues.apache.org/jira/browse/TS-817
 Project: Traffic Server
  Issue Type: Bug
  Components: TS API
Affects Versions: 3.0.0
Reporter: Naveen
  Labels: api-change, function
 Fix For: 3.3.0


 The API calls TSFetchUrl/TSFetchPages do not work with HTTP/1.1 requests. The 
 implementation seems to use the end of the connection to signal the user 
 callback function, which is not the case on persistent connections.

--
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