[jira] [Commented] (TS-1115) Fix build issues with Intel ICC

2012-02-18 Thread Leif Hedstrom (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211172#comment-13211172
 ] 

Leif Hedstrom commented on TS-1115:
---

Commit: 03d858fce9a5a028a61fd976c5062c2bd39956b0

I really wish git would post this automatically :/

 Fix build issues with Intel ICC
 ---

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


 Get it to compile cleanly, and run, with Intel ICC again.

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




[jira] [Created] (TS-1116) Fix build issues with clang (particularly on OSX)

2012-02-18 Thread Leif Hedstrom (Created) (JIRA)
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


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] [Commented] (TS-1116) Fix build issues with clang (particularly on OSX)

2012-02-18 Thread Leif Hedstrom (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211200#comment-13211200
 ] 

Leif Hedstrom commented on TS-1116:
---

I got most of it to compile, with the exception of this in IpMap.cc:

{code}
IpMap.cc:850:11: error: call to function 'operator' that is neither visible in 
the template definition nor found by argument-dependent lookup
if (x  n-_min) n = left(n);
  ^
IpMap.cc:1236:24: note: in instantiation of member function 
'ts::detail::IpMapBasets::detail::Ip6Node::contains' requested here
zret = _m6  _m6-contains(ink_inet_ip6_cast(target), ptr);
   ^
IpMap.cc:1164:13: note: 'operator' should be declared prior to the call site 
or in the global namespace
inline bool operator(sockaddr_in6 const* lhs, sockaddr_in6 const rhs) {
^
IpMap.cc:665:17: error: call to function 'operator==' that is neither visible 
in the template definition nor found by argument-dependent lookup
if (n-_min == min) {
^
IpMap.cc:1260:21: note: in instantiation of member function 
'ts::detail::IpMapBasets::detail::Ip6Node::mark' requested here
this-force6()-mark(ink_inet_ip6_cast(min), ink_inet_ip6_cast(max), data);
^
IpMap.cc:1172:13: note: 'operator==' should be declared prior to the call site 
or in the global namespace
inline bool operator==(sockaddr_in6 const lhs, sockaddr_in6 const* rhs) {
^
IpMap.cc:736:19: error: call to function 'operator=' that is neither visible 
in the template definition nor found by argument-dependent lookup
  if (n-_max = max_plus) { // completely covered, drop span, continue
  ^
IpMap.cc:1188:13: note: 'operator=' should be declared prior to the call site 
or in the global namespace
inline bool operator=(sockaddr_in6 const lhs, sockaddr_in6 const rhs) {
^
IpMap.cc:514:16: error: call to function 'operator' that is neither visible in 
the template definition nor found by argument-dependent lookup
if (target  n-_min) n = left(n);
   ^
IpMap.cc:640:16: note: in instantiation of member function 
'ts::detail::IpMapBasets::detail::Ip6Node::lowerBound' requested here
  N* n = this-lowerBound(min); // current node.
   ^
IpMap.cc:1260:21: note: in instantiation of member function 
'ts::detail::IpMapBasets::detail::Ip6Node::mark' requested here
this-force6()-mark(ink_inet_ip6_cast(min), ink_inet_ip6_cast(max), data);
^
IpMap.cc:1164:13: note: 'operator' should be declared prior to the call site 
or in the global namespace
inline bool operator(sockaddr_in6 const* lhs, sockaddr_in6 const rhs) {
^
4 errors generated.
{code}

I'll commit the other changes (after I test them on Linux), but I'll need 
assistant from some C++ propeller head with the template madness above :).

 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


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

2012-02-18 Thread 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)

2012-02-18 Thread 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

2012-02-18 Thread 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

2012-02-18 Thread 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

2012-02-18 Thread 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

2012-02-18 Thread 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

2012-02-18 Thread 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