[jira] [Updated] (TS-4046) HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4046:
--
Fix Version/s: 6.1.0

> HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest
> 
>
> Key: TS-4046
> URL: https://issues.apache.org/jira/browse/TS-4046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, MIME, Plugins
>Reporter: rienzi2012
>  Labels: review
> Fix For: 6.1.0
>
>
> HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy in 
> HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
> plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
> influences a lot of users. Here is a patch below.
> {code:java}
> @@ -892,7 +892,7 @@
>  HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
>  TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
>} else {
> -s->hdr_info.client_response.clear(); // anything previously set is 
> invalid from this point forward
> +s->hdr_info.client_response.destroy();
>  DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
>  
>  if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4046) HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4046:
--
Labels: review  (was: )

> HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest
> 
>
> Key: TS-4046
> URL: https://issues.apache.org/jira/browse/TS-4046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, MIME, Plugins
>Reporter: rienzi2012
>  Labels: review
> Fix For: 6.1.0
>
>
> HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy in 
> HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
> plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
> influences a lot of users. Here is a patch below.
> {code:java}
> @@ -892,7 +892,7 @@
>  HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
>  TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
>} else {
> -s->hdr_info.client_response.clear(); // anything previously set is 
> invalid from this point forward
> +s->hdr_info.client_response.destroy();
>  DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
>  
>  if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15034059#comment-15034059
 ] 

ASF GitHub Bot commented on TS-3072:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/350#issuecomment-161030286
  
Yeh I mean the latter. All the code in ```ContFlags``` boils down to 
getspecific + setspecific, the rest is really not necessary. A separate file 
with a class that is used only once (and it not really re-usable) spreads the 
code around in a way that makes it harder to follow.


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15034077#comment-15034077
 ] 

ASF GitHub Bot commented on TS-3072:


Github user shinrich commented on the pull request:

https://github.com/apache/trafficserver/pull/350#issuecomment-161034092
  
Originally, I just had an int pointer for the flags.  Then we were doing 
experiments with multiple flags, and it seemed like having a separate class 
with bit names was more readable.  

From a runtime implementation perspective, I think it is all about the same.


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15034040#comment-15034040
 ] 

ASF GitHub Bot commented on TS-3072:


Github user SolidWallOfCode commented on the pull request:

https://github.com/apache/trafficserver/pull/350#issuecomment-161026974
  
James - a `uintptr_t` instead of `ContFlags` would require the assumption a 
continuation always runs on the same thread, which is not the case. `ContFlags` 
ensures that the continuation gets the thread based flags regardless of the 
thread on which it executes. On the other hand if you mean doing the thread 
specific stuff in `Continuation` I would think it's clearly better to isolate 
that stuff in `ContFlags`.


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4048) Broken Vagrantfile in a lot of ways

[Christoph Keller (JIRA)]

Christoph Keller created TS-4048:


 Summary: Broken Vagrantfile in a lot of ways
 Key: TS-4048
 URL: https://issues.apache.org/jira/browse/TS-4048
 Project: Traffic Server
  Issue Type: Bug
  Components: Build, Tools
Reporter: Christoph Keller


The Vagrant-File seems to be broken.

1. I tried to "vagrant up centos64" which failed due to files that could not be 
downloaded during provisioning.

2. Saucy Images are no longer available and should be removed from Vagrantfile.

3. I guess it would be better to use sshfs instead of nfs for the shared folder 
due to the fact that a lot of people use encrypted home-directories these days 
which makes mounting the shared folder fail. You don't even get a proper 
errormessage for that.

I didn't check all resources refered to by either Vagrantfile or the puppet 
files but i guess there are even more broken links.







--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035398#comment-15035398
 ] 

ASF GitHub Bot commented on TS-3072:


Github user ushachar commented on the pull request:

https://github.com/apache/trafficserver/pull/350#issuecomment-161205132
  
To quote our own docs (under Admin Guide/Plugins):
"""
One of the key features of Apache Traffic Server™ is its modularity. 
Features that aren’t needed in the core simply aren’t there. This helps to 
provide an additional guarantee that our core can remain fast by concentrating 
on the things that we always provide: caching and proxying.
"""
I'd add that keeping things out of the core also makes it easier to 
understand, verify and debug.

The way I see it - Logic on when to enable debugging on a 
transaction/session can be arbitrarily complex. I'm sure everyone on this 
thread can see the use of enabling debugs based on things like cipher suites, 
TLS protocol version, destination IPs. Even when relying only on source IPs, 
you might want to enable for only one in ten connections to cut the logging 
volume.
Our (badly named :-) ) header_rewrite plugin can easily be adjusted to 
support such logic.
(Personally - my trigger to enable debugging is often determined in an 
external process that does policy matching)

@djcarlin - This being implemented in a plugin doesn't mean you'd have to 
restart ATS to use it -- The plugin would be loaded by default and you could 
enable/disable debugging by modifying it's configuration.
(You could even talk to it directly via traffic_line using @SolidWallOfCode 
latest work on TS-4032)


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4045) Improvement for ts_lua plugin

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035412#comment-15035412
 ] 

ASF subversion and git services commented on TS-4045:
-

Commit 2121859b3868e49631f128b7bea993e19eba2cc1 in trafficserver's branch 
refs/heads/master from [~kichan]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2121859 ]

TS-4045: improvement on ts_lua plugin. This closes #357


> Improvement for ts_lua plugin
> -
>
> Key: TS-4045
> URL: https://issues.apache.org/jira/browse/TS-4045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 6.1.0
>
>
> 3 things to accomplish in this jira
> 1) add support for TSHttpTxnDebugSet
> 2) protect http context pointer access in api calls
> 3) fix a spelling mistake from "truncked" to "truncated"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4046) HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest

[Oknet Xu (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035414#comment-15035414
 ] 

Oknet Xu commented on TS-4046:
--

do we need to replace "HdrHeap *m_heap" in HdrHeapSDKHandler with “Ptr 
m_heap” ？

{code}
475 inline void
476 HdrHeapSDKHandle::clear()
477 {
478   m_heap = NULL;   < mem leak as described in this issue if here is the 
last one to keep the memory area
479 }
{code}

> HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest
> 
>
> Key: TS-4046
> URL: https://issues.apache.org/jira/browse/TS-4046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, MIME, Plugins
>Reporter: rienzi2012
>  Labels: review
> Fix For: 6.1.0
>
>
> HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy in 
> HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
> plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
> influences a lot of users. Here is a patch below.
> {code:java}
> @@ -892,7 +892,7 @@
>  HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
>  TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
>} else {
> -s->hdr_info.client_response.clear(); // anything previously set is 
> invalid from this point forward
> +s->hdr_info.client_response.destroy();
>  DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
>  
>  if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4045) Improvement for ts_lua plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035413#comment-15035413
 ] 

ASF GitHub Bot commented on TS-4045:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/357


> Improvement for ts_lua plugin
> -
>
> Key: TS-4045
> URL: https://issues.apache.org/jira/browse/TS-4045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 6.1.0
>
>
> 3 things to accomplish in this jira
> 1) add support for TSHttpTxnDebugSet
> 2) protect http context pointer access in api calls
> 3) fix a spelling mistake from "truncked" to "truncated"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (TS-4045) Improvement for ts_lua plugin

[Kit Chan (JIRA)]

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

Work on TS-4045 started by Kit Chan.

> Improvement for ts_lua plugin
> -
>
> Key: TS-4045
> URL: https://issues.apache.org/jira/browse/TS-4045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 6.1.0
>
>
> 3 things to accomplish in this jira
> 1) add support for TSHttpTxnDebugSet
> 2) protect http context pointer access in api calls
> 3) fix a spelling mistake from "truncked" to "truncated"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4047) multiple -rpath options are not handled correctly

[James Peach (JIRA)]

James Peach created TS-4047:
---

 Summary: multiple -rpath options are not handled correctly
 Key: TS-4047
 URL: https://issues.apache.org/jira/browse/TS-4047
 Project: Traffic Server
  Issue Type: Bug
  Components: Build
Reporter: James Peach


https://github.com/apache/trafficserver/pull/324

{quote}
Using TS_ADDTO to add the custom locations of libraries results in incorrect 
"-rpath" directive to the linker. This is because TS_ADDTO creates a unique 
list of tokens that it adds to its target. E.g.,

./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib
the above should result in

LIBTOOL_LINK_FLAGS: -rpath /usr/local/openssl/lib /usr/local/zlib/lib
The absence of "-rpath" in front of the second path causes an error in the 
linker!

This is fixed by introducing a new macro TS_ADD_RPATH_TO that takes a path and 
adds it with the "-rpath " prefix.

Also added influential environmental variable RPATH that can be used to give a 
base value for the rpath. So, the following

./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib 
RPATH=/foo
will result in

LIBTOOL_LINK_FLAGS: -rpath /foo -rpath /usr/local/zlib/lib -rpath 
/usr/local/openssl/lib
{quote}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4047) multiple -rpath options are not handled correctly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035284#comment-15035284
 ] 

ASF GitHub Bot commented on TS-4047:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/324#issuecomment-161183921
  
I filed this as [TS-4047](https://issues.apache.org/jira/browse/TS-4047).


> multiple -rpath options are not handled correctly
> -
>
> Key: TS-4047
> URL: https://issues.apache.org/jira/browse/TS-4047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>
> https://github.com/apache/trafficserver/pull/324
> {quote}
> Using TS_ADDTO to add the custom locations of libraries results in incorrect 
> "-rpath" directive to the linker. This is because TS_ADDTO creates a unique 
> list of tokens that it adds to its target. E.g.,
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib
> the above should result in
> LIBTOOL_LINK_FLAGS: -rpath /usr/local/openssl/lib /usr/local/zlib/lib
> The absence of "-rpath" in front of the second path causes an error in the 
> linker!
> This is fixed by introducing a new macro TS_ADD_RPATH_TO that takes a path 
> and adds it with the "-rpath " prefix.
> Also added influential environmental variable RPATH that can be used to give 
> a base value for the rpath. So, the following
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib 
> RPATH=/foo
> will result in
> LIBTOOL_LINK_FLAGS: -rpath /foo -rpath /usr/local/zlib/lib -rpath 
> /usr/local/openssl/lib
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4047) multiple -rpath options are not handled correctly

[Brian Geffon (JIRA)]

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

Brian Geffon reassigned TS-4047:


Assignee: Brian Geffon

> multiple -rpath options are not handled correctly
> -
>
> Key: TS-4047
> URL: https://issues.apache.org/jira/browse/TS-4047
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: James Peach
>Assignee: Brian Geffon
>
> https://github.com/apache/trafficserver/pull/324
> {quote}
> Using TS_ADDTO to add the custom locations of libraries results in incorrect 
> "-rpath" directive to the linker. This is because TS_ADDTO creates a unique 
> list of tokens that it adds to its target. E.g.,
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib
> the above should result in
> LIBTOOL_LINK_FLAGS: -rpath /usr/local/openssl/lib /usr/local/zlib/lib
> The absence of "-rpath" in front of the second path causes an error in the 
> linker!
> This is fixed by introducing a new macro TS_ADD_RPATH_TO that takes a path 
> and adds it with the "-rpath " prefix.
> Also added influential environmental variable RPATH that can be used to give 
> a base value for the rpath. So, the following
> ./configure --with-openssl=/usr/local/openssl --with-zlib=/usr/local/zlib 
> RPATH=/foo
> will result in
> LIBTOOL_LINK_FLAGS: -rpath /foo -rpath /usr/local/zlib/lib -rpath 
> /usr/local/openssl/lib
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4045) Improvement for ts_lua plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033404#comment-15033404
 ] 

ASF GitHub Bot commented on TS-4045:


Github user shukitchan commented on the pull request:

https://github.com/apache/trafficserver/pull/357#issuecomment-160906831
  
@bgaff - updated with using macro. thank.


> Improvement for ts_lua plugin
> -
>
> Key: TS-4045
> URL: https://issues.apache.org/jira/browse/TS-4045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 6.1.0
>
>
> 3 things to accomplish in this jira
> 1) add support for TSHttpTxnDebugSet
> 2) protect http context pointer access in api calls
> 3) fix a spelling mistake from "truncked" to "truncated"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3986) Restore validations for flags of HTTP/2 Frame

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033440#comment-15033440
 ] 

ASF GitHub Bot commented on TS-3986:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/354


> Restore validations for flags of HTTP/2 Frame
> -
>
> Key: TS-3986
> URL: https://issues.apache.org/jira/browse/TS-3986
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 6.1.0
>
>
> In TS-3921, validations for flags of HTTP/2 Frame are commented out 
> temporally.
> The root causes, wrong masks of frame flags, are fixed now.
> So restore the validations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3986) Restore validations for flags of HTTP/2 Frame

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033438#comment-15033438
 ] 

ASF subversion and git services commented on TS-3986:
-

Commit f8621492a725db05f5e5f87998f4f90dc7a59941 in trafficserver's branch 
refs/heads/master from [~masaori]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f862149 ]

TS-3986: Cleanup code related to HTTP/2 frame flags validation

1. Rename http2_are_frame_flags_valid to http2_frame_flags_are_valid
2. Move list of masks to HTTP2.h from HTTP2.cc

This closes #354


> Restore validations for flags of HTTP/2 Frame
> -
>
> Key: TS-3986
> URL: https://issues.apache.org/jira/browse/TS-3986
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 6.1.0
>
>
> In TS-3921, validations for flags of HTTP/2 Frame are commented out 
> temporally.
> The root causes, wrong masks of frame flags, are fixed now.
> So restore the validations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4045) Improvement for ts_lua plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033315#comment-15033315
 ] 

ASF GitHub Bot commented on TS-4045:


Github user shukitchan commented on the pull request:

https://github.com/apache/trafficserver/pull/357#issuecomment-160890632
  
@jpeach , would really appreciate if you can take a look and review.


> Improvement for ts_lua plugin
> -
>
> Key: TS-4045
> URL: https://issues.apache.org/jira/browse/TS-4045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 6.1.0
>
>
> 3 things to accomplish in this jira
> 1) add support for TSHttpTxnDebugSet
> 2) protect http context pointer access in api calls
> 3) fix a spelling mistake from "truncked" to "truncated"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4045) Improvement for ts_lua plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1504#comment-1504
 ] 

ASF GitHub Bot commented on TS-4045:


Github user bgaff commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/357#discussion_r46250788
  
--- Diff: plugins/experimental/ts_lua/ts_lua_client_request.c ---
@@ -332,6 +348,10 @@ ts_lua_client_request_get_pristine_url(lua_State *L)
   ts_lua_http_ctx *http_ctx;
 
   http_ctx = ts_lua_get_http_ctx(L);
+  if (http_ctx == NULL) {
--- End diff --

given that this pattern is literally repeated everywhere, perhaps a macro 
is in order:
```
#define GET_CONTEXT(ctx, list) \
  ctx = ts_lua_get_http_ctx(list); \
  if (ctx == NULL) { \
   TS_ERROR(...); \
   return; \
  }
```


> Improvement for ts_lua plugin
> -
>
> Key: TS-4045
> URL: https://issues.apache.org/jira/browse/TS-4045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 6.1.0
>
>
> 3 things to accomplish in this jira
> 1) add support for TSHttpTxnDebugSet
> 2) protect http context pointer access in api calls
> 3) fix a spelling mistake from "truncked" to "truncated"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4045) Improvement for ts_lua plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033310#comment-15033310
 ] 

ASF GitHub Bot commented on TS-4045:


GitHub user shukitchan opened a pull request:

https://github.com/apache/trafficserver/pull/357

TS-4045: ts_lua improvements

3 things to accomplish in this jira

1) add support for TSHttpTxnDebugSet
2) protect http context pointer access in api calls
3) fix a spelling mistake from "truncked" to "truncated"

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shukitchan/trafficserver TS-4045

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/357.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #357


commit 706829c55d017f7b275fde7c61571eed2bbb31e0
Author: Kit Chan 
Date:   2015-12-01T08:09:46Z

TS-4045: ts_lua improvements




> Improvement for ts_lua plugin
> -
>
> Key: TS-4045
> URL: https://issues.apache.org/jira/browse/TS-4045
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Kit Chan
>Assignee: Kit Chan
> Fix For: 6.1.0
>
>
> 3 things to accomplish in this jira
> 1) add support for TSHttpTxnDebugSet
> 2) protect http context pointer access in api calls
> 3) fix a spelling mistake from "truncked" to "truncated"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4032) Provide command line alert feature for plugins

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033846#comment-15033846
 ] 

ASF GitHub Bot commented on TS-4032:


Github user SolidWallOfCode commented on the pull request:

https://github.com/apache/trafficserver/pull/343#issuecomment-160998361
  
I hand marshall the message from `traffic_manager` to `traffic_server` 
because the technique you suggest did not work for me. What I did was pass the 
raw message data, which should be the same thing as you suggested (because the 
raw data is the marshalled message from `traffic_ctl`). But I saw no way to 
unmarshall the data when it arrives in `traffic_server`. If you know how to do 
that, feel free to fix this after it's committed.


> Provide command line alert feature for plugins
> --
>
> Key: TS-4032
> URL: https://issues.apache.org/jira/browse/TS-4032
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Labels: Review
> Fix For: 6.1.0
>
>
> Add another event  to the lifecycle hook, ALERT. This will be sent only from 
> an external API, e.g. {{traffic_ctl}}. Any plugin that wants to be alertable 
> from the command line can attach to this hook and watch for the event 
> {{TS_EVENT_LIFECYCLE_ALERT}}. The data for the event wil be a string that is 
> provided by the external agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4032) Provide command line alert feature for plugins

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033851#comment-15033851
 ] 

ASF GitHub Bot commented on TS-4032:


Github user SolidWallOfCode commented on the pull request:

https://github.com/apache/trafficserver/pull/343#issuecomment-160998970
  
I need to work on the documentation a bit more before I send it out for 
formal API review. I would also like to build better example / use case code. 
It might well be that in that process I tweak the API to better suit actual use.


> Provide command line alert feature for plugins
> --
>
> Key: TS-4032
> URL: https://issues.apache.org/jira/browse/TS-4032
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Labels: Review
> Fix For: 6.1.0
>
>
> Add another event  to the lifecycle hook, ALERT. This will be sent only from 
> an external API, e.g. {{traffic_ctl}}. Any plugin that wants to be alertable 
> from the command line can attach to this hook and watch for the event 
> {{TS_EVENT_LIFECYCLE_ALERT}}. The data for the event wil be a string that is 
> provided by the external agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4046) HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest

[rienzi2012 (JIRA)]

rienzi2012 created TS-4046:
--

 Summary: HdrHeap and HdrStrHeap leak in 
HttpTransact::EndRemapRequest
 Key: TS-4046
 URL: https://issues.apache.org/jira/browse/TS-4046
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP, MIME, Plugins
Reporter: rienzi2012


{code:java}
@@ -892,7 +892,7 @@
 HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
 TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
   } else {
-s->hdr_info.client_response.clear(); // anything previously set is invalid 
from this point forward
+s->hdr_info.client_response.destroy();
 DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
 
 if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4046) HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest

[rienzi2012 (JIRA)]

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

rienzi2012 updated TS-4046:
---
Description: 
HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy() in 
HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
influences a lot of users. Here is a patch below.
{code:java}
@@ -892,7 +892,7 @@
 HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
 TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
   } else {
-s->hdr_info.client_response.clear(); // anything previously set is invalid 
from this point forward
+s->hdr_info.client_response.destroy();
 DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
 
 if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
{code}

  was:
{code:java}
@@ -892,7 +892,7 @@
 HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
 TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
   } else {
-s->hdr_info.client_response.clear(); // anything previously set is invalid 
from this point forward
+s->hdr_info.client_response.destroy();
 DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
 
 if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
{code}


> HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest
> 
>
> Key: TS-4046
> URL: https://issues.apache.org/jira/browse/TS-4046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, MIME, Plugins
>Reporter: rienzi2012
>
> HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy() in 
> HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
> plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
> influences a lot of users. Here is a patch below.
> {code:java}
> @@ -892,7 +892,7 @@
>  HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
>  TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
>} else {
> -s->hdr_info.client_response.clear(); // anything previously set is 
> invalid from this point forward
> +s->hdr_info.client_response.destroy();
>  DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
>  
>  if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4046) HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest

[rienzi2012 (JIRA)]

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

rienzi2012 updated TS-4046:
---
Description: 
HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy in 
HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
influences a lot of users. Here is a patch below.
{code:java}
@@ -892,7 +892,7 @@
 HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
 TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
   } else {
-s->hdr_info.client_response.clear(); // anything previously set is invalid 
from this point forward
+s->hdr_info.client_response.destroy();
 DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
 
 if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
{code}

  was:
HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy() in 
HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
influences a lot of users. Here is a patch below.
{code:java}
@@ -892,7 +892,7 @@
 HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
 TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
   } else {
-s->hdr_info.client_response.clear(); // anything previously set is invalid 
from this point forward
+s->hdr_info.client_response.destroy();
 DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
 
 if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
{code}


> HdrHeap and HdrStrHeap leak in HttpTransact::EndRemapRequest
> 
>
> Key: TS-4046
> URL: https://issues.apache.org/jira/browse/TS-4046
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, MIME, Plugins
>Reporter: rienzi2012
>
> HTTPHdr::clear is called instead of HdrHeapSDKHandle::destroy in 
> HttpTransact::EndRemapRequest. This will definitely cause memory leak when a 
> plugin calls TSHttpTxnServerIntercept or TSHttpTxnIntercept. This bug 
> influences a lot of users. Here is a patch below.
> {code:java}
> @@ -892,7 +892,7 @@
>  HTTP_INCREMENT_TRANS_STAT(http_invalid_client_requests_stat);
>  TRANSACT_RETURN(SM_ACTION_SEND_ERROR_CACHE_NOOP, NULL);
>} else {
> -s->hdr_info.client_response.clear(); // anything previously set is 
> invalid from this point forward
> +s->hdr_info.client_response.destroy();
>  DebugTxn("http_trans", "END HttpTransact::EndRemapRequest");
>  
>  if (s->is_upgrade_request && s->post_remap_upgrade_return_point) {
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4032) Provide command line alert feature for plugins

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15033979#comment-15033979
 ] 

ASF GitHub Bot commented on TS-4032:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/343#issuecomment-161019315
  
Message marshaling works just fine, see #301 for an example of exactly what 
you want to do here. If you can show me the problem then I can try to help.


> Provide command line alert feature for plugins
> --
>
> Key: TS-4032
> URL: https://issues.apache.org/jira/browse/TS-4032
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>  Labels: Review
> Fix For: 6.1.0
>
>
> Add another event  to the lifecycle hook, ALERT. This will be sent only from 
> an external API, e.g. {{traffic_ctl}}. Any plugin that wants to be alertable 
> from the command line can attach to this hook and watch for the event 
> {{TS_EVENT_LIFECYCLE_ALERT}}. The data for the event wil be a string that is 
> provided by the external agent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3072) Debug logging for a single connection in production traffic.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15034021#comment-15034021
 ] 

ASF GitHub Bot commented on TS-3072:


Github user jpeach commented on the pull request:

https://github.com/apache/trafficserver/pull/350#issuecomment-161024984
  
The whole ```ContFlags``` class seems unnecessary. If you really need 
per-thread flags, then why not just keep a thread-specify ```uintptr_t``` in 
the ```Continuation```?


> Debug logging for a single connection in production traffic.
> 
>
> Key: TS-3072
> URL: https://issues.apache.org/jira/browse/TS-3072
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Logging
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
>Assignee: Susan Hinrichs
>  Labels: Yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3072.diff
>
>
> Presently, when there's a production issue (e.g. TS-3049, TS-2983 etc), it is 
> really hard to isolate/debug with the high traffic. Turning on debug logs in 
> traffic is unfortunately not an option due to performance impacts. Even if 
> you took a performance hit and turned on the logs, it is just as hard to 
> separate out the logs for a single connection/transaction among the millions 
> of the logs output in a short period of time.
> I think it would be good if there's a way to turn on debug logs in a 
> controlled manner in production environment. One simple option is to support 
> a config setting for example, with a client-ip, which when set, would turn on 
> debug logs for any connection made by just that one client. If needed, 
> instead of one client-ip, we may allow configuring up to 'n' (say, 5) 
> client-ips. 
> If there are other ideas, please comment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)