[jira] [Work logged] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4716?focusedWorklogId=26501=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26501
 ]

ASF GitHub Bot logged work on TS-4716:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 05:23
Start Date: 16/Aug/16 05:23
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/438/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26501)
Time Spent: 1h  (was: 50m)

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[GitHub] trafficserver issue #869: TS-4716: Install manpages in $PREFIX/share/man.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/438/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4716?focusedWorklogId=26500=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26500
 ]

ASF GitHub Bot logged work on TS-4716:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 05:18
Start Date: 16/Aug/16 05:18
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/541/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26500)
Time Spent: 50m  (was: 40m)

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[jira] [Updated] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[James Peach (JIRA)]

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

James Peach updated TS-4716:

Backport to Version:   (was: 6.2.1)

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[GitHub] trafficserver issue #869: TS-4716: Install manpages in $PREFIX/share/man.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/541/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4716?focusedWorklogId=26498=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26498
 ]

ASF GitHub Bot logged work on TS-4716:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:53
Start Date: 16/Aug/16 04:53
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/540/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26498)
Time Spent: 0.5h  (was: 20m)

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[jira] [Work logged] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4716?focusedWorklogId=26499=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26499
 ]

ASF GitHub Bot logged work on TS-4716:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:53
Start Date: 16/Aug/16 04:53
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/437/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26499)
Time Spent: 40m  (was: 0.5h)

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[GitHub] trafficserver issue #869: TS-4716: Install manpages in $PREFIX/share/man.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/540/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #869: TS-4716: Install manpages in $PREFIX/share/man.

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/437/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #869: TS-4716: Install manpages in $PREFIX/share/man.

[jpeach]

Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
@zwoop perl installs its manages into the wrong place  any ideas?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4716?focusedWorklogId=26497=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26497
 ]

ASF GitHub Bot logged work on TS-4716:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:51
Start Date: 16/Aug/16 04:51
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
@zwoop perl installs its manages into the wrong place  any ideas?


Issue Time Tracking
---

Worklog Id: (was: 26497)
Time Spent: 20m  (was: 10m)

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[jira] [Work logged] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4716?focusedWorklogId=26496=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26496
 ]

ASF GitHub Bot logged work on TS-4716:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:41
Start Date: 16/Aug/16 04:41
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

TS-4716: Install manpages in $PREFIX/share/man.

Update various layouts to default to installing manpages into
$PREFIX/share/man. Some layouts already did this, but it is probably
worth making it the default for people who just configure with
--prefix=/PATH.

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

$ git pull https://github.com/jpeach/trafficserver fix/4716

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

https://github.com/apache/trafficserver/pull/869.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 #869


commit 681c1393737555fafa3728e04a559201856c1490
Author: James Peach 
Date:   2016-08-16T04:38:28Z

TS-4716: Install manpages in $PREFIX/share/man.

Update various layouts to default to installing manpages into
$PREFIX/share/man. Some layouts already did this, but it is probably
worth making it the default for people who just configure with
--prefix=/PATH.




Issue Time Tracking
---

Worklog Id: (was: 26496)
Time Spent: 10m
Remaining Estimate: 0h

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> 

[GitHub] trafficserver pull request #869: TS-4716: Install manpages in $PREFIX/share/...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4716: Install manpages in $PREFIX/share/man.

Update various layouts to default to installing manpages into
$PREFIX/share/man. Some layouts already did this, but it is probably
worth making it the default for people who just configure with
--prefix=/PATH.

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

$ git pull https://github.com/jpeach/trafficserver fix/4716

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

https://github.com/apache/trafficserver/pull/869.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 #869


commit 681c1393737555fafa3728e04a559201856c1490
Author: James Peach 
Date:   2016-08-16T04:38:28Z

TS-4716: Install manpages in $PREFIX/share/man.

Update various layouts to default to installing manpages into
$PREFIX/share/man. Some layouts already did this, but it is probably
worth making it the default for people who just configure with
--prefix=/PATH.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[James Peach (JIRA)]

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

James Peach commented on TS-4716:
-

Man page installation is defaulted by {{config.layout}}. You can override with 
{{--mandir}} at configure time.

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



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

[jira] [Work logged] (TS-4184) Move to use the C++11 standard

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4184?focusedWorklogId=26495=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26495
 ]

ASF GitHub Bot logged work on TS-4184:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:19
Start Date: 16/Aug/16 04:19
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/858
  
Looks good


Issue Time Tracking
---

Worklog Id: (was: 26495)
Time Spent: 50m  (was: 40m)

> Move to use the C++11 standard
> --
>
> Key: TS-4184
> URL: https://issues.apache.org/jira/browse/TS-4184
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Require C++0x and get rid of ats_scoped_resource based classes.



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

[GitHub] trafficserver issue #858: TS-4184 Makes -std=c++11 mandatory

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/858
  
Looks good


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: clang-analyzer #2538

[jenkins]

See 

Changes:

[James Peach] TS-4548: Add lua_getfield helper.

[James Peach] TS-4548: Convert logs_xml.config to Lua.

[James Peach] TS-4548: Remove enable_lua.

[James Peach] TS-4548: Apply clang-format to libbindings.

[James Peach] TS-4548: Add a Lua stack helper class.

--
[...truncated 4963 lines...]
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldNextDup.en
reading sources... [ 54%] developer-guide/api/functions/TSMimeHdrFieldRemove.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueAppend.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateInsert.en
reading sources... [ 54%] 
developer-guide/api/functions/TSMimeHdrFieldValueDateSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueIntSet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringGet.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringInsert.en
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 56%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 59%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 60%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 62%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSUuidCreate.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 66%] 

[jira] [Work logged] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4719?focusedWorklogId=26494=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26494
 ]

ASF GitHub Bot logged work on TS-4719:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:17
Start Date: 16/Aug/16 04:17
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/868
  
 - Looks good


Issue Time Tracking
---

Worklog Id: (was: 26494)
Time Spent: 40m  (was: 0.5h)

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[GitHub] trafficserver issue #868: TS-4719: Make AIO threads interleave memory across...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/868
  
👍 - Looks good


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4751) revalidation can skip updating the Age header

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4751?focusedWorklogId=26493=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26493
 ]

ASF GitHub Bot logged work on TS-4751:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:13
Start Date: 16/Aug/16 04:13
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/864
  
@jpeach I would be OK with deleting the Expires header, but I think we 
should keep the Cache-Control, Last-Modified, and Vary.


Issue Time Tracking
---

Worklog Id: (was: 26493)
Time Spent: 1h 40m  (was: 1.5h)

> revalidation can skip updating the Age header
> -
>
> Key: TS-4751
> URL: https://issues.apache.org/jira/browse/TS-4751
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> In {{HttpTransact::merge_and_update_headers_for_cache_update}}, the cached 
> {{Age}} header is only updated if the server response also contains an 
> {{Age}} header. If the revalidation response does not contain an {{Age}}, we 
> will retain the cache {{Age}} header which makes the document permanently 
> stale, causing a revalidation on every request.



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

[GitHub] trafficserver issue #864: TS-4751: Prune cached headers before merging the u...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/864
  
@jpeach I would be OK with deleting the Expires header, but I think we 
should keep the Cache-Control, Last-Modified, and Vary.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (TS-4548) Convert custom log config file to Lua

[James Peach (JIRA)]

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

James Peach resolved TS-4548.
-
Resolution: Fixed

> Convert custom log config file to Lua
> -
>
> Key: TS-4548
> URL: https://issues.apache.org/jira/browse/TS-4548
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Custom logs {{logs_xml.config}} is a good candidate to convert to Lua 
> bindings. I'm thinking that we bind fairly directly to the internal logging 
> objects so that conceptually it is the same but instead of using XML to 
> construct objects, you use Lua. We would just construct Lua states on the fly 
> to evaluate the file.
> This is the last usage of XML and would let us nuke {{proxy/shared/InkXml.*}} 
> as well as our dependencies on expat+libxml2.



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

[jira] [Work logged] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?focusedWorklogId=26492=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26492
 ]

ASF GitHub Bot logged work on TS-4750:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 04:00
Start Date: 16/Aug/16 04:00
Worklog Time Spent: 10m 
  Work Description: Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/863
  
@zwoop Looks good to me!
@shinrich we are defined too many get_remote_*() method, my suggest is only 
keep one from get_remote_addr() and get_remote_endpoint()


Issue Time Tracking
---

Worklog Id: (was: 26492)
Time Spent: 1h 20m  (was: 1h 10m)

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



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

[GitHub] trafficserver issue #863: TS-4750: Fix Connection Leak warnings.

[oknet]

Github user oknet commented on the issue:

https://github.com/apache/trafficserver/pull/863
  
@zwoop Looks good to me!
@shinrich we are defined too many get_remote_*() method, my suggest is only 
keep one from get_remote_addr() and get_remote_endpoint()


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4548) Convert custom log config file to Lua

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4548?focusedWorklogId=26491=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26491
 ]

ASF GitHub Bot logged work on TS-4548:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 03:55
Start Date: 16/Aug/16 03:55
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 26491)
Time Spent: 2h 20m  (was: 2h 10m)

> Convert custom log config file to Lua
> -
>
> Key: TS-4548
> URL: https://issues.apache.org/jira/browse/TS-4548
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Custom logs {{logs_xml.config}} is a good candidate to convert to Lua 
> bindings. I'm thinking that we bind fairly directly to the internal logging 
> objects so that conceptually it is the same but instead of using XML to 
> construct objects, you use Lua. We would just construct Lua states on the fly 
> to evaluate the file.
> This is the last usage of XML and would let us nuke {{proxy/shared/InkXml.*}} 
> as well as our dependencies on expat+libxml2.



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

[GitHub] trafficserver pull request #851: TS-4548: Convert custom log config file to ...

[jpeach]

Github user jpeach closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #351: TS-4042: Add feature to buffer request body before...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/351
  
Looking over the pull request I didn't see any limits on how much is going 
to be buffered on the server.  It might be good to start the transfer to the 
origin once a configurable limite gets reached.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4042) Add feature to buffer request body before making downstream requests

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4042?focusedWorklogId=26490=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26490
 ]

ASF GitHub Bot logged work on TS-4042:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 03:38
Start Date: 16/Aug/16 03:38
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/351
  
Looking over the pull request I didn't see any limits on how much is going 
to be buffered on the server.  It might be good to start the transfer to the 
origin once a configurable limite gets reached.


Issue Time Tracking
---

Worklog Id: (was: 26490)
Time Spent: 0.5h  (was: 20m)

> Add feature to buffer request body before making downstream requests
> 
>
> Key: TS-4042
> URL: https://issues.apache.org/jira/browse/TS-4042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, CPP API, TS API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We need a way to examine the request body without making a downstream 
> request, this feature has many use cases including:
>   - Ability to buffer the body and ensure a full post is received before 
> committing downstream resources.
>   - Ability to choose an origin based on request body
>   - Ability to do request content filtering such as a WAF might provide 
> before the origin is involved.
> Today you have two options to inspect a request body:
>   1) Transformations: the problem with transformations is that you only start 
> receiving the request bytes after a sink has been established, which in this 
> case is the downstream origin.
>   2) Create an intercept and use fetch apis to then send the downstream 
> request: while this technically works it turns out to be a ton of code and is 
> in general pretty problematic, we actually tried this approach for a while 
> and had nothing but problems with it.
> We feel it would be ideal if we could intercept the body without breaking the 
> normal ATS state flow. There used to exist code (and it's still in the core 
> just #ifdefed out) to drain the request body. I use that code as the basis 
> for this request buffering code. We added APIs to both the C and C++ APIs so 
> that this request buffering can be enabled from a plugin and the plugin can 
> inspect the body as chunks arrive or when it's complete. We've included an 
> example plugin that will error a transaction if a minimum rate of transfer is 
> not maintained.
> I'm confident that this feature will bring plenty of questions / feedback, so 
> let's get that party started.



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

[jira] [Work logged] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4719?focusedWorklogId=26489=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26489
 ]

ASF GitHub Bot logged work on TS-4719:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 03:28
Start Date: 16/Aug/16 03:28
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/868
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/436/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26489)
Time Spent: 0.5h  (was: 20m)

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[GitHub] trafficserver issue #868: TS-4719: Make AIO threads interleave memory across...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/868
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/436/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4719?focusedWorklogId=26488=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26488
 ]

ASF GitHub Bot logged work on TS-4719:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 03:23
Start Date: 16/Aug/16 03:23
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/868
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/539/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26488)
Time Spent: 20m  (was: 10m)

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[GitHub] trafficserver issue #868: TS-4719: Make AIO threads interleave memory across...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/868
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/539/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4719) Should have NUMA affinity for disk threads (AIO threads)

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4719?focusedWorklogId=26487=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26487
 ]

ASF GitHub Bot logged work on TS-4719:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 03:14
Start Date: 16/Aug/16 03:14
Worklog Time Spent: 10m 
  Work Description: GitHub user PSUdaemon opened a pull request:

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

TS-4719: Make AIO threads interleave memory across NUMA nodes.



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

$ git pull https://github.com/PSUdaemon/trafficserver ts-4719

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

https://github.com/apache/trafficserver/pull/868.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 #868


commit e5261f4d5edf557fe03571b46eacc61d430425e3
Author: Phil Sorber 
Date:   2016-08-16T03:13:26Z

TS-4719: Make AIO threads interleave memory across NUMA nodes.




Issue Time Tracking
---

Worklog Id: (was: 26487)
Time Spent: 10m
Remaining Estimate: 0h

> Should have NUMA affinity for disk threads (AIO threads)
> 
>
> Key: TS-4719
> URL: https://issues.apache.org/jira/browse/TS-4719
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache, Core
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should properly interleave AIO threads (disk threads) evenly across the 
> NUMA nodes, and have affinity on those nodes. That would allow for better 
> memory distribution across NUMA nodes. We've noticed pretty uneven 
> allocations on some boxes, which I attribute to this problem (but no strong 
> evidence, but it does make sense).
> {code}
> Per-node process memory usage (in MBs) for PID 33471 ([ET_NET 0])
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.000.000.00
> Stack1.380.642.02
> Private 188993.7559142.80   248136.55
>   --- --- ---
> Total   188995.1359143.44   248138.57
> {code}



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

[GitHub] trafficserver pull request #868: TS-4719: Make AIO threads interleave memory...

[PSUdaemon]

GitHub user PSUdaemon opened a pull request:

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

TS-4719: Make AIO threads interleave memory across NUMA nodes.



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

$ git pull https://github.com/PSUdaemon/trafficserver ts-4719

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

https://github.com/apache/trafficserver/pull/868.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 #868


commit e5261f4d5edf557fe03571b46eacc61d430425e3
Author: Phil Sorber 
Date:   2016-08-16T03:13:26Z

TS-4719: Make AIO threads interleave memory across NUMA nodes.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4584?focusedWorklogId=26486=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26486
 ]

ASF GitHub Bot logged work on TS-4584:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 02:31
Start Date: 16/Aug/16 02:31
Worklog Time Spent: 10m 
  Work Description: Github user alhonen commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Scoped pointer approach posted.


Issue Time Tracking
---

Worklog Id: (was: 26486)
Time Spent: 2h 40m  (was: 2.5h)

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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

[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

[alhonen]

Github user alhonen commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Scoped pointer approach posted.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4584?focusedWorklogId=26485=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26485
 ]

ASF GitHub Bot logged work on TS-4584:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 02:28
Start Date: 16/Aug/16 02:28
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/435/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26485)
Time Spent: 2.5h  (was: 2h 20m)

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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

[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/435/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #351: TS-4042: Add feature to buffer request body...

[bryancall]

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

https://github.com/apache/trafficserver/pull/351#discussion_r74867909
  
--- Diff: proxy/InkAPI.cc ---
@@ -8903,3 +8910,46 @@ TSVConnReenable(TSVConn vconn)
 }
   }
 }
+
+tsapi char *
+TSHttpTxnGetClientRequestBody(TSHttpTxn txnp, int *len)
--- End diff --

Why are you adding this API if you are not using it?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4042) Add feature to buffer request body before making downstream requests

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4042?focusedWorklogId=26484=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26484
 ]

ASF GitHub Bot logged work on TS-4042:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 02:24
Start Date: 16/Aug/16 02:24
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/351#discussion_r74867909
  
--- Diff: proxy/InkAPI.cc ---
@@ -8903,3 +8910,46 @@ TSVConnReenable(TSVConn vconn)
 }
   }
 }
+
+tsapi char *
+TSHttpTxnGetClientRequestBody(TSHttpTxn txnp, int *len)
--- End diff --

Why are you adding this API if you are not using it?


Issue Time Tracking
---

Worklog Id: (was: 26484)
Time Spent: 20m  (was: 10m)

> Add feature to buffer request body before making downstream requests
> 
>
> Key: TS-4042
> URL: https://issues.apache.org/jira/browse/TS-4042
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, CPP API, TS API
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We need a way to examine the request body without making a downstream 
> request, this feature has many use cases including:
>   - Ability to buffer the body and ensure a full post is received before 
> committing downstream resources.
>   - Ability to choose an origin based on request body
>   - Ability to do request content filtering such as a WAF might provide 
> before the origin is involved.
> Today you have two options to inspect a request body:
>   1) Transformations: the problem with transformations is that you only start 
> receiving the request bytes after a sink has been established, which in this 
> case is the downstream origin.
>   2) Create an intercept and use fetch apis to then send the downstream 
> request: while this technically works it turns out to be a ton of code and is 
> in general pretty problematic, we actually tried this approach for a while 
> and had nothing but problems with it.
> We feel it would be ideal if we could intercept the body without breaking the 
> normal ATS state flow. There used to exist code (and it's still in the core 
> just #ifdefed out) to drain the request body. I use that code as the basis 
> for this request buffering code. We added APIs to both the C and C++ APIs so 
> that this request buffering can be enabled from a plugin and the plugin can 
> inspect the body as chunks arrive or when it's complete. We've included an 
> example plugin that will error a transaction if a minimum rate of transfer is 
> not maintained.
> I'm confident that this feature will bring plenty of questions / feedback, so 
> let's get that party started.



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

[jira] [Work logged] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4584?focusedWorklogId=26483=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26483
 ]

ASF GitHub Bot logged work on TS-4584:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 02:23
Start Date: 16/Aug/16 02:23
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/538/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26483)
Time Spent: 2h 20m  (was: 2h 10m)

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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

[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/538/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4042) Add feature to buffer request body before making downstream requests

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4042?focusedWorklogId=26482=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26482
 ]

ASF GitHub Bot logged work on TS-4042:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 02:22
Start Date: 16/Aug/16 02:22
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/351#discussion_r74867804
  
--- Diff: plugins/request_buffer/request_buffer.cc ---
@@ -0,0 +1,119 @@
+/* request_buffer.cc - Plugin to enable request buffer for the given 
transaction.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ts/ts.h"
+#include "ts/ink_defs.h"
+
+#define PLUGIN_NAME "request_buffer"
+
+static const int MIN_BYTE_PER_SEC = 1000;
+static int TXN_INDEX_ARG_TIME;
+struct TimeRecord {
+  timespec start_time;
+  TimeRecord() { clock_gettime(CLOCK_MONOTONIC, _time); }
+};
+bool
+is_post_request(TSHttpTxn txnp)
+{
+  const char *method;
+  int method_len;
+  TSMLoc req_loc;
+  TSMBuffer req_bufp;
+  if (TSHttpTxnClientReqGet(txnp, _bufp, _loc) == TS_ERROR) {
+TSError("Error while retrieving client request header\n");
+return false;
+  }
+  method = TSHttpHdrMethodGet(req_bufp, req_loc, _len);
+  if (static_cast(method_len) != strlen(TS_HTTP_METHOD_POST) || 
strncasecmp(method, TS_HTTP_METHOD_POST, method_len) != 0) {
+TSHandleMLocRelease(req_bufp, TS_NULL_MLOC, req_loc);
+return false;
+  }
+  TSHandleMLocRelease(req_bufp, TS_NULL_MLOC, req_loc);
+  return true;
+}
+bool
+reached_min_speed(TSHttpTxn txnp, int body_len)
+{
+  TimeRecord *timeRecord = (TimeRecord *)TSHttpTxnArgGet(txnp, 
TXN_INDEX_ARG_TIME);
+  timespec now_time;
+  clock_gettime(CLOCK_MONOTONIC, _time);
+  double time_diff_in_sec =
+(now_time.tv_sec - timeRecord->start_time.tv_sec) + 1e-9 * 
(now_time.tv_nsec - timeRecord->start_time.tv_nsec);
+  TSDebug("http", "time_diff_in_sec = %f, body_len = %d, date_rate = 
%f\n", time_diff_in_sec, body_len,
+  body_len / time_diff_in_sec);
+  return body_len / time_diff_in_sec >= MIN_BYTE_PER_SEC;
+}
+static int
+hook_handler(TSCont contp, TSEvent event, void *edata)
+{
+  TSHttpTxn txnp = (TSHttpTxn)(edata);
+  if (event == TS_EVENT_HTTP_READ_REQUEST_HDR && is_post_request(txnp)) {
+// enable the request body buffering
+TSHttpTxnConfigIntSet(txnp, TS_CONFIG_HTTP_REQUEST_BUFFER_ENABLED, 1);
+
+// save the start time for calculating the data rate
+TimeRecord *timeRecord = new TimeRecord();
+TSHttpTxnArgSet(txnp, TXN_INDEX_ARG_TIME, static_cast(timeRecord));
+
+TSHttpTxnHookAdd(txnp, TS_HTTP_REQUEST_BUFFER_READ_HOOK, 
TSContCreate(hook_handler, TSMutexCreate()));
+TSHttpTxnHookAdd(txnp, TS_HTTP_REQUEST_BUFFER_READ_COMPLETE_HOOK, 
TSContCreate(hook_handler, TSMutexCreate()));
+TSHttpTxnHookAdd(txnp, TS_HTTP_TXN_CLOSE_HOOK, 
TSContCreate(hook_handler, TSMutexCreate()));
+  } else if (event == TS_EVENT_HTTP_REQUEST_BUFFER_READ || event == 
TS_EVENT_HTTP_REQUEST_BUFFER_COMPLETE) {
+int64_t ret_len = TSHttpTxnClientReqBodyBytesGet(txnp);
+if (event == TS_EVENT_HTTP_REQUEST_BUFFER_READ && 
!reached_min_speed(txnp, ret_len)) {
+  TSError("[hook_handler] Error : reached_min_speed checking 
failed\n");
+  TSHttpTxnReenable(txnp, TS_EVENT_ERROR);
+  return 0;
+}
+
+// get the received request body
+TSIOBufferReader buffer_reader = 
TSHttpTxnGetClientRequestBufferReader(txnp);
+int64_t read_avail = TSIOBufferReaderAvail(buffer_reader);
+if (read_avail) {
+  char *body = (char *)TSmalloc(sizeof(char) * read_avail);
+  int64_t consumed = 0;
+  int64_t data_len = 0;
+  const char *char_data = NULL;
+  TSIOBufferBlock block = TSIOBufferReaderStart(buffer_reader);
+  while (block != NULL) {
+char_data = TSIOBufferBlockReadStart(block, buffer_reader, 
_len);
+memcpy(body + consumed, char_data, data_len);
+consumed += data_len;
+block = TSIOBufferBlockNext(block);
+  }
+  // play with the body
--- End diff --

Why are you copying the body if you aren't doing anything with it?


Issue Time Tracking
---

Worklog Id: (was: 26482)
Time Spent: 10m
Remaining Estimate: 0h

> Add feature to buffer request body before making downstream requests
> 
>
> Key: TS-4042
> URL: 

[GitHub] trafficserver pull request #351: TS-4042: Add feature to buffer request body...

[bryancall]

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

https://github.com/apache/trafficserver/pull/351#discussion_r74867804
  
--- Diff: plugins/request_buffer/request_buffer.cc ---
@@ -0,0 +1,119 @@
+/* request_buffer.cc - Plugin to enable request buffer for the given 
transaction.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ts/ts.h"
+#include "ts/ink_defs.h"
+
+#define PLUGIN_NAME "request_buffer"
+
+static const int MIN_BYTE_PER_SEC = 1000;
+static int TXN_INDEX_ARG_TIME;
+struct TimeRecord {
+  timespec start_time;
+  TimeRecord() { clock_gettime(CLOCK_MONOTONIC, _time); }
+};
+bool
+is_post_request(TSHttpTxn txnp)
+{
+  const char *method;
+  int method_len;
+  TSMLoc req_loc;
+  TSMBuffer req_bufp;
+  if (TSHttpTxnClientReqGet(txnp, _bufp, _loc) == TS_ERROR) {
+TSError("Error while retrieving client request header\n");
+return false;
+  }
+  method = TSHttpHdrMethodGet(req_bufp, req_loc, _len);
+  if (static_cast(method_len) != strlen(TS_HTTP_METHOD_POST) || 
strncasecmp(method, TS_HTTP_METHOD_POST, method_len) != 0) {
+TSHandleMLocRelease(req_bufp, TS_NULL_MLOC, req_loc);
+return false;
+  }
+  TSHandleMLocRelease(req_bufp, TS_NULL_MLOC, req_loc);
+  return true;
+}
+bool
+reached_min_speed(TSHttpTxn txnp, int body_len)
+{
+  TimeRecord *timeRecord = (TimeRecord *)TSHttpTxnArgGet(txnp, 
TXN_INDEX_ARG_TIME);
+  timespec now_time;
+  clock_gettime(CLOCK_MONOTONIC, _time);
+  double time_diff_in_sec =
+(now_time.tv_sec - timeRecord->start_time.tv_sec) + 1e-9 * 
(now_time.tv_nsec - timeRecord->start_time.tv_nsec);
+  TSDebug("http", "time_diff_in_sec = %f, body_len = %d, date_rate = 
%f\n", time_diff_in_sec, body_len,
+  body_len / time_diff_in_sec);
+  return body_len / time_diff_in_sec >= MIN_BYTE_PER_SEC;
+}
+static int
+hook_handler(TSCont contp, TSEvent event, void *edata)
+{
+  TSHttpTxn txnp = (TSHttpTxn)(edata);
+  if (event == TS_EVENT_HTTP_READ_REQUEST_HDR && is_post_request(txnp)) {
+// enable the request body buffering
+TSHttpTxnConfigIntSet(txnp, TS_CONFIG_HTTP_REQUEST_BUFFER_ENABLED, 1);
+
+// save the start time for calculating the data rate
+TimeRecord *timeRecord = new TimeRecord();
+TSHttpTxnArgSet(txnp, TXN_INDEX_ARG_TIME, static_cast(timeRecord));
+
+TSHttpTxnHookAdd(txnp, TS_HTTP_REQUEST_BUFFER_READ_HOOK, 
TSContCreate(hook_handler, TSMutexCreate()));
+TSHttpTxnHookAdd(txnp, TS_HTTP_REQUEST_BUFFER_READ_COMPLETE_HOOK, 
TSContCreate(hook_handler, TSMutexCreate()));
+TSHttpTxnHookAdd(txnp, TS_HTTP_TXN_CLOSE_HOOK, 
TSContCreate(hook_handler, TSMutexCreate()));
+  } else if (event == TS_EVENT_HTTP_REQUEST_BUFFER_READ || event == 
TS_EVENT_HTTP_REQUEST_BUFFER_COMPLETE) {
+int64_t ret_len = TSHttpTxnClientReqBodyBytesGet(txnp);
+if (event == TS_EVENT_HTTP_REQUEST_BUFFER_READ && 
!reached_min_speed(txnp, ret_len)) {
+  TSError("[hook_handler] Error : reached_min_speed checking 
failed\n");
+  TSHttpTxnReenable(txnp, TS_EVENT_ERROR);
+  return 0;
+}
+
+// get the received request body
+TSIOBufferReader buffer_reader = 
TSHttpTxnGetClientRequestBufferReader(txnp);
+int64_t read_avail = TSIOBufferReaderAvail(buffer_reader);
+if (read_avail) {
+  char *body = (char *)TSmalloc(sizeof(char) * read_avail);
+  int64_t consumed = 0;
+  int64_t data_len = 0;
+  const char *char_data = NULL;
+  TSIOBufferBlock block = TSIOBufferReaderStart(buffer_reader);
+  while (block != NULL) {
+char_data = TSIOBufferBlockReadStart(block, buffer_reader, 
_len);
+memcpy(body + consumed, char_data, data_len);
+consumed += data_len;
+block = TSIOBufferBlockNext(block);
+  }
+  // play with the body
--- End diff --

Why are you copying the body if you aren't doing anything with it?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4584?focusedWorklogId=26481=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26481
 ]

ASF GitHub Bot logged work on TS-4584:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 02:18
Start Date: 16/Aug/16 02:18
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/537/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26481)
Time Spent: 2h 10m  (was: 2h)

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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

[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/537/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4584?focusedWorklogId=26480=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26480
 ]

ASF GitHub Bot logged work on TS-4584:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 02:08
Start Date: 16/Aug/16 02:08
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/434/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26480)
Time Spent: 2h  (was: 1h 50m)

> CID 1254818: Resource leak on file descriptor and allocated memory
> --
>
> Key: TS-4584
> URL: https://issues.apache.org/jira/browse/TS-4584
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Jari Alhonen
>Assignee: Jari Alhonen
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> ClusterMachine.cc leaks file descriptors and allocated memory in certain 
> error conditions.



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

[GitHub] trafficserver issue #803: TS-4584: Resource leak, CID 1254818 and 1254809

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/803
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/434/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-2134) SRV lookup does not handle failover correctly

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-2134:


This should be fixed in 7.x (not sure exactly which patch, but I have tested 
that case). If someone else wants to verify that'd be great :)

> SRV lookup does not handle failover correctly
> -
>
> Key: TS-2134
> URL: https://issues.apache.org/jira/browse/TS-2134
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS, HTTP
>Reporter: Thach Tran
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: ats.log, ts2134.patch
>
>
> I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail 
> over to alternative origins once the first choice is marked as down.
> To reproduce this, I'm running dnsmasq as a local resolver to serve up the 
> test SRV records. My configuration is as follows.
> h4. records.config
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING NULL
> CONFIG proxy.config.srv_enabled INT 1
> h4. remap.config
> regex_remap http://.*:8080/ https://noexample.com/
> h4. dnsmasq.conf (srv records config)
> srv-host=_http._tcp.noexample.com,abc.com,443,0,100
> srv-host=_http._tcp.noexample.com,google.com,443,1,100
> The intention is since the srv lookup for _http._tcp.noexample.com returns 
> abc.com:443 and google.com:443 with abc.com:443 being the one with higher 
> priority, the proxy should try that first and once the connection to 
> abc.com:443 is marked as down (up to 6 retries by default), google.com:443 
> should be tried next and the connection should succeed then.
> However, testing with the following curl command multiple times still gives 
> back 502.
> $ curl -v http://localhost:8080/
> Debug log seems to suggest it always attempts abc.com:443.



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

[GitHub] trafficserver pull request #863: TS-4750: Fix Connection Leak warnings.

[jpeach]

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

https://github.com/apache/trafficserver/pull/863#discussion_r74860215
  
--- Diff: iocore/net/I_NetVConnection.h ---
@@ -482,6 +482,7 @@ class NetVConnection : public VConnection
 
   /** Returns remote sockaddr storage. */
   sockaddr const *get_remote_addr();
+  IpEndpoint const _remote_endpoint();
--- End diff --

How intrusive is it to make these const methods?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?focusedWorklogId=26479=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26479
 ]

ASF GitHub Bot logged work on TS-4750:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 00:34
Start Date: 16/Aug/16 00:34
Worklog Time Spent: 10m 
  Work Description: Github user jpeach commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/863#discussion_r74860215
  
--- Diff: iocore/net/I_NetVConnection.h ---
@@ -482,6 +482,7 @@ class NetVConnection : public VConnection
 
   /** Returns remote sockaddr storage. */
   sockaddr const *get_remote_addr();
+  IpEndpoint const _remote_endpoint();
--- End diff --

How intrusive is it to make these const methods?


Issue Time Tracking
---

Worklog Id: (was: 26479)
Time Spent: 1h 10m  (was: 1h)

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



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

[jira] [Work logged] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?focusedWorklogId=26478=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26478
 ]

ASF GitHub Bot logged work on TS-4750:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 00:27
Start Date: 16/Aug/16 00:27
Worklog Time Spent: 10m 
  Work Description: Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/863
  
Seems straightforward.  


Issue Time Tracking
---

Worklog Id: (was: 26478)
Time Spent: 1h  (was: 50m)

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



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

[jira] [Created] (TS-4758) back up the state machine after parent proxy failures

[James Peach (JIRA)]

James Peach created TS-4758:
---

 Summary: back up the state machine after parent proxy failures
 Key: TS-4758
 URL: https://issues.apache.org/jira/browse/TS-4758
 Project: Traffic Server
  Issue Type: Improvement
  Components: Parent Proxy
Reporter: James Peach


I don't have a good idea how to handle this, but it would be helpful if plugins 
could get a second chance of a parent proxy fails. The situation now is that 
you have to call {{TSHttpTxnParentProxySet}} and cross your fingers. It would 
be a lot better if the state machine backed up to a hook when the parent proxy 
failed. OS-DNS would be a convenient hook, but it will be hard to restart 
sanely from there since there is a log if state around the DNS result. Maybe a 
new hook would make sense since that could also be used with 
{{TSHttpTxnServerAddrSet}}.



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

[jira] [Work logged] (TS-2237) URL encoding wrong in squid.blog

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2237?focusedWorklogId=26477=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26477
 ]

ASF GitHub Bot logged work on TS-2237:
--

Author: ASF GitHub Bot
Created on: 16/Aug/16 00:18
Start Date: 16/Aug/16 00:18
Worklog Time Spent: 10m 
  Work Description: Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
``HttpRequestData::get_string()`` unescapes an URL and it is called from 
``UrlMatcher::Match(RequestData *rdata, Result *result)``. I 
think this is the code Sudheer mentioned.

However, at least, the unescaped URL doesn't come out from the function. If 
we could assure that no unescaped string flows into the logging system, we will 
be able to simply remove some of calls of ``LogUtils::url_escapify``.

Also, I realized that ``TSStringPercentEncode`` uses 
``LogUtils::url_escapify`` internally. So changing behavior of 
``LogUtils::url_escapify`` would affect plugins.


Issue Time Tracking
---

Worklog Id: (was: 26477)
Time Spent: 2.5h  (was: 2h 20m)

> URL encoding wrong in squid.blog
> 
>
> Key: TS-2237
> URL: https://issues.apache.org/jira/browse/TS-2237
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: David Carlin
>Priority: Minor
>  Labels: yahoo
> Fix For: sometime
>
> Attachments: TS-2237.diff
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> I was replaying URLs captured from squid.blog and I noticed I was getting 
> 404's for some of them when squid.blog showed a 200 for that request.  Turns 
> out there is an issue with URL encoding.  For example:
> Requesting file 'duck%20sports%20authority.gif' via curl will put this in the 
> logs:
> duck%2520sports%2520authority.gif
> The % from %20 (space) in the request is being converted to %25 resulting in 
> %2520
> I tested both the % and % log fields - same thing happens.  I 
> tested on ATS 3.2.0 and 3.3.5



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

[GitHub] trafficserver issue #866: TS-2237: Fix double encoding of URLs in squid logs...

[maskit]

Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
``HttpRequestData::get_string()`` unescapes an URL and it is called from 
``UrlMatcher::Match(RequestData *rdata, Result *result)``. I 
think this is the code Sudheer mentioned.

However, at least, the unescaped URL doesn't come out from the function. If 
we could assure that no unescaped string flows into the logging system, we will 
be able to simply remove some of calls of ``LogUtils::url_escapify``.

Also, I realized that ``TSStringPercentEncode`` uses 
``LogUtils::url_escapify`` internally. So changing behavior of 
``LogUtils::url_escapify`` would affect plugins.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4757) parent proxy API to go direct

[James Peach (JIRA)]

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

James Peach updated TS-4757:

Issue Type: Improvement  (was: Bug)

> parent proxy API to go direct
> -
>
> Key: TS-4757
> URL: https://issues.apache.org/jira/browse/TS-4757
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy, TS API
>Reporter: James Peach
>
> Once you call {{TSHttpTxnParentProxySet}} there is no way to undo that and no 
> way to ask for the transaction to go direct if the parent is unavailable.
> There's 2 possible cases:
> 1. Force a transaction to go direct after {{TSHttpTxnParentProxySet}} was set 
> (ie. undo its effects).
> 2. Allow a parent transaction to go direct if the parent fails (equivalent to 
> the {{go_direct}} configuration setting).



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

[GitHub] trafficserver issue #855: fix the memory leaks

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/855
  
Also would have a Jira # in the subject line please.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TS-4757) parent proxy API to go direct

[James Peach (JIRA)]

James Peach created TS-4757:
---

 Summary: parent proxy API to go direct
 Key: TS-4757
 URL: https://issues.apache.org/jira/browse/TS-4757
 Project: Traffic Server
  Issue Type: Bug
  Components: Parent Proxy, TS API
Reporter: James Peach


Once you call {{TSHttpTxnParentProxySet}} there is no way to undo that and no 
way to ask for the transaction to go direct if the parent is unavailable.

There's 2 possible cases:
1. Force a transaction to go direct after {{TSHttpTxnParentProxySet}} was set 
(ie. undo its effects).
2. Allow a parent transaction to go direct if the parent fails (equivalent to 
the {{go_direct}} configuration setting).



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

[jira] [Commented] (TS-4026) Remove clustering feature in 7.0.0 release

[James Peach (JIRA)]

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

James Peach commented on TS-4026:
-

Recently a couple of people popped up on the dev list reporting some success 
(and some bugs) with clustering.

> Remove clustering feature in 7.0.0 release 
> ---
>
> Key: TS-4026
> URL: https://issues.apache.org/jira/browse/TS-4026
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Clustering
>Reporter: Bryan Call
>  Labels: incompatible
> Fix For: 7.0.0
>
>
> From the ATS Fall Summit 2015 no one said they where using the clustering 
> feature.



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

[jira] [Updated] (TS-4743) parent use consistent_hash Strategy may cause crash while first parent is not set

[James Peach (JIRA)]

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

James Peach updated TS-4743:

Summary: parent use consistent_hash Strategy may cause crash while first 
parent is not set   (was: parent use consitent_hash Strategy may cause crash 
while first parent is not set )

> parent use consistent_hash Strategy may cause crash while first parent is not 
> set 
> --
>
> Key: TS-4743
> URL: https://issues.apache.org/jira/browse/TS-4743
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: xiangdong chen
> Fix For: 7.0.0
>
>
> my parent.config
> eg :
> dest_domain=.  secondary_parent="192.168.104.229:80|1.0; 
> 192.168.104.182:80|1.0"  round_robin=consistent_hash
> the crash place is :
> DEBUG:  (parent_select) 
> wrap_around[PRIMARY]: 1, wrap_around[SECONDARY]: 0
> traffic_server: Segmentation fault (Address not mapped to object [0x10])
> ParentConsistentHash.cc:167 code:
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec->hostname);
> Fix the code like
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec ? pRec->hostname:"[NULL]");



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

[jira] [Updated] (TS-4743) parent use consistent_hash Strategy may cause crash while first parent is not set

[James Peach (JIRA)]

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

James Peach updated TS-4743:

Assignee: John Rushford

> parent use consistent_hash Strategy may cause crash while first parent is not 
> set 
> --
>
> Key: TS-4743
> URL: https://issues.apache.org/jira/browse/TS-4743
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> my parent.config
> eg :
> dest_domain=.  secondary_parent="192.168.104.229:80|1.0; 
> 192.168.104.182:80|1.0"  round_robin=consistent_hash
> the crash place is :
> DEBUG:  (parent_select) 
> wrap_around[PRIMARY]: 1, wrap_around[SECONDARY]: 0
> traffic_server: Segmentation fault (Address not mapped to object [0x10])
> ParentConsistentHash.cc:167 code:
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec->hostname);
> Fix the code like
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec ? pRec->hostname:"[NULL]");



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

[jira] [Updated] (TS-4743) parent use consistent_hash Strategy may cause crash while first parent is not set

[James Peach (JIRA)]

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

James Peach updated TS-4743:

Fix Version/s: 7.0.0

> parent use consistent_hash Strategy may cause crash while first parent is not 
> set 
> --
>
> Key: TS-4743
> URL: https://issues.apache.org/jira/browse/TS-4743
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> my parent.config
> eg :
> dest_domain=.  secondary_parent="192.168.104.229:80|1.0; 
> 192.168.104.182:80|1.0"  round_robin=consistent_hash
> the crash place is :
> DEBUG:  (parent_select) 
> wrap_around[PRIMARY]: 1, wrap_around[SECONDARY]: 0
> traffic_server: Segmentation fault (Address not mapped to object [0x10])
> ParentConsistentHash.cc:167 code:
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec->hostname);
> Fix the code like
> Debug("parent_select", "Selected parent %s is not available, looking up 
> another parent.", pRec ? pRec->hostname:"[NULL]");



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

[jira] [Work logged] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2048?focusedWorklogId=26476=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26476
 ]

ASF GitHub Bot logged work on TS-2048:
--

Author: ASF GitHub Bot
Created on: 15/Aug/16 23:13
Start Date: 15/Aug/16 23:13
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/867
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/433/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26476)
Time Spent: 40m  (was: 0.5h)

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[GitHub] trafficserver issue #867: TS-2048 Avoids scheduling CFLUS compressor when no...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/867
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/433/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2048?focusedWorklogId=26475=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26475
 ]

ASF GitHub Bot logged work on TS-2048:
--

Author: ASF GitHub Bot
Created on: 15/Aug/16 23:08
Start Date: 15/Aug/16 23:08
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/867
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/536/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26475)
Time Spent: 0.5h  (was: 20m)

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[GitHub] trafficserver issue #867: TS-2048 Avoids scheduling CFLUS compressor when no...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/867
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/536/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #867: TS-2048 Avoids scheduling CFLUS compressor when no...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/867
  
👍 - Looks good


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-2194) Alternate renderers for HTTP UI

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2194:
---
Summary: Alternate renderers for HTTP UI  (was: alternate renderers for 
HTTP UI)

> Alternate renderers for HTTP UI
> ---
>
> Key: TS-2194
> URL: https://issues.apache.org/jira/browse/TS-2194
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Tools
>Reporter: James Peach
>Assignee: James Peach
> Fix For: sometime
>
>
> While reviewing TS-2191, I realized that TS gathers a lot of useful debugging 
> information that is only published in the Web UI pages. We should make more 
> of this information available to command line tools (eg. via traffic_line or 
> SIGINFO, etc).



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

[jira] [Updated] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2193:
---
Assignee: (was: Gancho Tenev)

> Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
> --
>
> Key: TS-2193
> URL: https://issues.apache.org/jira/browse/TS-2193
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 4.1.2
>Reporter: Tommy Lee
>  Labels: Crash
> Fix For: sometime
>
> Attachments: bt-01.txt
>
>
> Hi all,
>   I've tried to enable DNS Thread without luck.
>   When i set proxy.config.dns.dedicated_thread to 1, it crashes with the 
> information below.
>   The ATS is working in Forward Proxy mode.
>   Thanks in advance.
> --
> traffic.out
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/cache-4.1/bin/traffic_server - STACK TRACE: 
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2af714875cb0]
> /usr/local/cache-4.1/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK_MD5P6HttpSM+0x52)[0x51dac2]
> /usr/local/cache-4.1/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12ContinuationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x51e0f1]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x53644c]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6a0)[0x537560]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x57e)[0x53743e]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM27state_hostdb_reverse_lookupEiPv+0xb9)[0x526b99]
> /usr/local/cache-4.1/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x531be8]
> /usr/local/cache-4.1/bin/traffic_server[0x5d7c8a]
> /usr/local/cache-4.1/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x821)[0x5decd1]
> /usr/local/cache-4.1/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5f7a94]
> /usr/local/cache-4.1/bin/traffic_server[0x5fd382]
> /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler8recv_dnsEiP5Event+0x852)[0x5fee72]
> /usr/local/cache-4.1/bin/traffic_server(_ZN10DNSHandler9mainEventEiP5Event+0x14)[0x5ffd94]
> /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x91)[0x6b2a41]
> /usr/local/cache-4.1/bin/traffic_server(_ZN7EThread7executeEv+0x514)[0x6b3534]
> /usr/local/cache-4.1/bin/traffic_server[0x6b17ea]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x2af71486de9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2af71558dccd]



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

[jira] [Work logged] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2048?focusedWorklogId=26473=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26473
 ]

ASF GitHub Bot logged work on TS-2048:
--

Author: ASF GitHub Bot
Created on: 15/Aug/16 22:59
Start Date: 15/Aug/16 22:59
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-2048 Avoids scheduling CFLUS compressor when not enabled



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

$ git pull https://github.com/zwoop/trafficserver TS-2048

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

https://github.com/apache/trafficserver/pull/867.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 #867


commit 9e33135c73765e7aeac94a2cb3b6e9aab58a0014
Author: Leif Hedstrom 
Date:   2016-08-15T22:56:30Z

TS-2048 Avoids scheduling CFLUS compressor when not enabled




Issue Time Tracking
---

Worklog Id: (was: 26473)
Time Spent: 10m
Remaining Estimate: 0h

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[jira] [Work logged] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2048?focusedWorklogId=26474=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26474
 ]

ASF GitHub Bot logged work on TS-2048:
--

Author: ASF GitHub Bot
Created on: 15/Aug/16 23:00
Start Date: 15/Aug/16 23:00
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/867
  
 - Looks good


Issue Time Tracking
---

Worklog Id: (was: 26474)
Time Spent: 20m  (was: 10m)

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[GitHub] trafficserver pull request #867: TS-2048 Avoids scheduling CFLUS compressor ...

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-2048 Avoids scheduling CFLUS compressor when not enabled



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

$ git pull https://github.com/zwoop/trafficserver TS-2048

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

https://github.com/apache/trafficserver/pull/867.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 #867


commit 9e33135c73765e7aeac94a2cb3b6e9aab58a0014
Author: Leif Hedstrom 
Date:   2016-08-15T22:56:30Z

TS-2048 Avoids scheduling CFLUS compressor when not enabled




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-2182) Setting proxy.config.net.sock_recv_buffer_size_out seriously affects performance

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2182:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Setting proxy.config.net.sock_recv_buffer_size_out seriously affects 
> performance
> 
>
> Key: TS-2182
> URL: https://issues.apache.org/jira/browse/TS-2182
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, Network
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>
> I still need to do some more testing, but setting
> {code}
> CONFIG proxy.config.net.sock_recv_buffer_size_out INT 256K
> {code}
> on my box reduces throughput to a (fast, local) Origin by about 1000x. 
> Throughput went from 18MB/sec to 15KB/sec. Removing this setting, restored 
> normal performance.



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

[jira] [Updated] (TS-2181) Add an identifier ID to remap rules, and corresponding log tag and plugin APIs

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2181:
---
Fix Version/s: (was: sometime)
   7.2.0

> Add an identifier ID to remap rules, and corresponding log tag and plugin APIs
> --
>
> Key: TS-2181
> URL: https://issues.apache.org/jira/browse/TS-2181
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging, Remap API
>Reporter: Leif Hedstrom
>Assignee: John Rushford
> Fix For: 7.2.0
>
>
> It would be useful to be able to have an identifier (not necessarily unique) 
> in remap rules. Something like e.g.
> {code}
> map http://example.com http://a.example.com @id="Rule 1"
> {code}
> Where the ID can be any freeform string up to say 32 characters (fixed size 
> for efficient APIs). In addition, we would also add a new log tag, RID or 
> some such, which can be used in custom log formats.
> Finally, since not all remapping happens through remap.config, we'd want to 
> add two new APIs as well (this is where the fixed size string comes to play, 
> to avoid allocations):
> {code}
> const char* TSRemapIdentifierGet();
> {code}
> and
> {code}
> TSReturnCode TSRemapIdentifierSet(const char* str);
> {code}
> The string is guaranteed to be NULL terminated (for the Get()'er to be safe 
> and easy to use).
> Question: Does it makes sense to instead use a (char*, int) to pass along ? I 
> think not personally, and we have precedence in both (in marshaled buffers, 
> this makes more sense).



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

[jira] [Updated] (TS-2181) Add an identifier ID to remap rules, and corresponding log tag and plugin APIs

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2181:
---
Assignee: John Rushford

> Add an identifier ID to remap rules, and corresponding log tag and plugin APIs
> --
>
> Key: TS-2181
> URL: https://issues.apache.org/jira/browse/TS-2181
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging, Remap API
>Reporter: Leif Hedstrom
>Assignee: John Rushford
> Fix For: sometime
>
>
> It would be useful to be able to have an identifier (not necessarily unique) 
> in remap rules. Something like e.g.
> {code}
> map http://example.com http://a.example.com @id="Rule 1"
> {code}
> Where the ID can be any freeform string up to say 32 characters (fixed size 
> for efficient APIs). In addition, we would also add a new log tag, RID or 
> some such, which can be used in custom log formats.
> Finally, since not all remapping happens through remap.config, we'd want to 
> add two new APIs as well (this is where the fixed size string comes to play, 
> to avoid allocations):
> {code}
> const char* TSRemapIdentifierGet();
> {code}
> and
> {code}
> TSReturnCode TSRemapIdentifierSet(const char* str);
> {code}
> The string is guaranteed to be NULL terminated (for the Get()'er to be safe 
> and easy to use).
> Question: Does it makes sense to instead use a (char*, int) to pass along ? I 
> think not personally, and we have precedence in both (in marshaled buffers, 
> this makes more sense).



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

[jira] [Updated] (TS-2171) cluster.config is undocumented

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2171:
---
Issue Type: Improvement  (was: Bug)

> cluster.config is undocumented
> --
>
> Key: TS-2171
> URL: https://issues.apache.org/jira/browse/TS-2171
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Igor Galić
>Assignee: Jon Sime
> Fix For: Docs
>
>
> Ignoring its default configuration file in our tree, {cluster.config} is 
> undocumented.
> We should change this.



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

[jira] [Updated] (TS-2166) Response header to ua has two "Content-Range" field

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2166:
---
Fix Version/s: (was: 7.0.0)
   7.2.0

> Response header to ua has two "Content-Range" field
> ---
>
> Key: TS-2166
> URL: https://issues.apache.org/jira/browse/TS-2166
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 3.2.4, 4.2.0
>Reporter: portl4t
>Assignee: Alan M. Carroll
> Fix For: 7.2.0
>
>
> Follow these steps to reproduce:
> 1. TrafficServer cache a document which has "Etag" field in response header
> 2. The document expires.
> 3. UA sends request with "Range" field to this document.
> 4. TrafficServer sends request with IMS field to origin server to revalidate 
> this document
> 5. Origin Server sends response which has 304 code and "Content-Range" field 
> to TrafficServer
> 6. TrafficServer will generate another "Content-Range" field in 
> RangeTransform.
> {code}
> HTTP/1.1 206 Partial Content
> Date: Thu, 29 Aug 2013 03:09:05 GMT
> Content-Type: application/octet-stream
> Cache-Control: public
> Content-Disposition: attachment;
> Content-Encoding: utf-8
> ETag: "F68ADB16DB4F1EF87D93D665CC1FFF54"
> Expires: Tue,13 August 2013 07:04:10 GMT
> Last-Modified: Tue, 13 Aug 2013 07:04:14 GMT
> Server: ATS/3.2.0
> x-oss-request-id: 521EBB51E369AA445D2F48B9
> Accept-Ranges: bytes
> Content-Range: bytes 0-4243537/4243538
> Content-Range: bytes 0-4243537/4243538
> Content-Length: 4243538
> Age: 0
> Via: http/1.1 l2cn202 (ATS [cSsNfU])
> {code}



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

[jira] [Updated] (TS-2153) traffic_manager -tsArgs without -M is fatal error

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2153:
---
Fix Version/s: (was: sometime)
   7.1.0

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[jira] [Updated] (TS-2153) traffic_manager -tsArgs without -M is fatal error

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2153:
---
Assignee: Tyler Stroh

> traffic_manager -tsArgs without -M is fatal error
> -
>
> Key: TS-2153
> URL: https://issues.apache.org/jira/browse/TS-2153
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Adam Twardowski
>Assignee: Tyler Stroh
>  Labels: newbie
> Fix For: 7.1.0
>
>
> traffic_manager -tsArgs -T 'log.*'
> Running the above command on the 4.0.0 branch commit 
> c8931df15e33924bb459d40859a0b49331a6dbaf
> resulted in no running traffic_server and the following ps output
> nobody   16807  0.1  0.9 410884 18272 pts/0Sl+  16:58   0:00 
> traffic_manager -tsArgs -T log.*
> nobody   16816  0.0  0.0  0 0 pts/0Z+   16:58   0:00 
> [traffic_manager] 
> root 16818  0.0  0.0 103240   864 pts/1S+   16:59   0:00 grep tr
> manger.log output
> --
> [Aug 23 17:09:52.965] {0x7f61127b07e0} STATUS: opened 
> /usr/local/var/log/trafficserver/manager.log
> [Aug 23 17:09:52.966] {0x7f61127b07e0} NOTE: updated diags config
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [main] Traffic Server 
> Args: ' -T log.*'
> [Aug 23 17:09:52.967] Manager {0x7f61127b07e0} NOTE: [ClusterCom::ClusterCom] 
> Node running on OS: 'Linux' Release: '2.6.32-358.el6.x86_64'
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::listenForProxy] Listening on port: 80
> [Aug 23 17:09:52.968] Manager {0x7f61127b07e0} NOTE: [TrafficManager] Setup 
> complete
> [Aug 23 17:09:53.986] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::startProxy] Launching ts process
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL: 
> [LocalManager::startProxy] ts options must contain -M
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} FATAL:  (last system error 0: 
> Success)
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Aug 23 17:09:53.989] Manager {0x7f61127b07e0} NOTE: 
> [LocalManager::processShutdown] Executing process shutdown request.



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

[jira] [Updated] (TS-2164) Race condition between NetProcessor and api_init()

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll updated TS-2164:

Fix Version/s: (was: 7.0.0)
   7.1.0

> Race condition between NetProcessor and api_init()
> --
>
> Key: TS-2164
> URL: https://issues.apache.org/jira/browse/TS-2164
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Tomasz Kuzemko
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> In proxy/Main.cc starting of NetProcessor before calling api_init() can lead 
> to a segfault when an early connection is served because of accessing 
> http_global_hooks in HttpClientSession::new_connection():
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffe5019700 (LWP 21479)]
> 0x00564add in HttpClientSession::new_connection (this=0x15073c0, 
> new_vc=0x152df20, backdoor=false) at HttpClientSession.cc:228
> 228 hooks_set = http_global_hooks->hooks_set;



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

[jira] [Updated] (TS-2140) Stats module is showing proxy.process.cache.direntries.used greater then proxy.process.cache.direntries.total

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2140:
---
Fix Version/s: (was: 7.0.0)
   sometime

> Stats module is showing proxy.process.cache.direntries.used greater then 
> proxy.process.cache.direntries.total
> -
>
> Key: TS-2140
> URL: https://issues.apache.org/jira/browse/TS-2140
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics
>Affects Versions: 3.3.4
>Reporter: Adam Twardowski
>Assignee: Alan M. Carroll
>Priority: Minor
> Fix For: sometime
>
>
> using the stats_over_http.so module, reported 
> proxy.process.cache.direntries.used is greater then 
> proxy.process.cache.direntries.total
> Also, direntries.used is continuously increasing over time.  traffic_line -r 
>  gives the same numbers as the http stats.
> { "global": {
> "proxy.process.version.server.short": "3.3.4-dev",
> "proxy.process.version.server.long": "Apache Traffic Server - traffic_server 
> - 3.3.4-dev - (build # 63013 on Jul 30 2013 at 13:23:55)",
> "proxy.process.version.server.build_number": "63013",
> "proxy.process.version.server.build_time": "13:23:55",
> "proxy.process.version.server.build_date": "Jul 30 2013",
> "proxy.process.version.server.build_machine": "X",
> "proxy.process.version.server.build_person": "root",
> "proxy.process.http.completed_requests": "1771631878",
> "proxy.process.http.total_incoming_connections": "1771779452",
> "proxy.process.http.total_client_connections": "1771779452",
> "proxy.process.http.total_client_connections_ipv4": "1771779452",
> "proxy.process.http.total_client_connections_ipv6": "0",
> "proxy.process.http.total_server_connections": "486478731",
> "proxy.process.http.total_parent_proxy_connections": "0",
> "proxy.process.http.avg_transactions_per_client_connection": "1.15",
> "proxy.process.http.avg_transactions_per_server_connection": "1.00",
> "proxy.process.http.avg_transactions_per_parent_connection": "0.00",
> "proxy.process.http.client_connection_time": "0",
> "proxy.process.http.parent_proxy_connection_time": "0",
> "proxy.process.http.server_connection_time": "0",
> "proxy.process.http.cache_connection_time": "0",
> "proxy.process.http.transaction_counts.errors.pre_accept_hangups": "0",
> "proxy.process.http.transaction_totaltime.errors.pre_accept_hangups": 
> "0.00",
> "proxy.process.http.transaction_counts.errors.empty_hangups": "0",
> "proxy.process.http.transaction_totaltime.errors.empty_hangups": "0.00",
> "proxy.process.http.transaction_counts.errors.early_hangups": "0",
> "proxy.process.http.transaction_totaltime.errors.early_hangups": "0.00",
> "proxy.process.http.incoming_requests": "1766073976",
> "proxy.process.http.outgoing_requests": "484585207",
> "proxy.process.http.incoming_responses": "486478535",
> "proxy.process.http.invalid_client_requests": "240",
> "proxy.process.http.missing_host_hdr": "0",
> "proxy.process.http.get_requests": "1765677046",
> "proxy.process.http.head_requests": "392884",
> "proxy.process.http.trace_requests": "8",
> "proxy.process.http.options_requests": "1562",
> "proxy.process.http.post_requests": "662",
> "proxy.process.http.put_requests": "7",
> "proxy.process.http.push_requests": "0",
> "proxy.process.http.delete_requests": "0",
> "proxy.process.http.purge_requests": "0",
> "proxy.process.http.connect_requests": "0",
> "proxy.process.http.extension_method_requests": "1807",
> "proxy.process.http.client_no_cache_requests": "0",
> "proxy.process.http.broken_server_connections": "63475",
> "proxy.process.http.cache_lookups": "1765896837",
> "proxy.process.http.cache_writes": "119147534",
> "proxy.process.http.cache_updates": "7812961",
> "proxy.process.http.cache_deletes": "60058",
> "proxy.process.http.tunnels": "5017",
> "proxy.process.http.throttled_proxy_only": "0",
> "proxy.process.http.request_taxonomy.i0_n0_m0": "0",
> "proxy.process.http.request_taxonomy.i1_n0_m0": "0",
> "proxy.process.http.request_taxonomy.i0_n1_m0": "0",
> "proxy.process.http.request_taxonomy.i1_n1_m0": "0",
> "proxy.process.http.request_taxonomy.i0_n0_m1": "0",
> "proxy.process.http.request_taxonomy.i1_n0_m1": "0",
> "proxy.process.http.request_taxonomy.i0_n1_m1": "0",
> "proxy.process.http.request_taxonomy.i1_n1_m1": "0",
> "proxy.process.http.icp_suggested_lookups": "0",
> "proxy.process.http.client_transaction_time": "0",
> "proxy.process.http.client_write_time": "0",
> "proxy.process.http.server_read_time": "0",
> "proxy.process.http.icp_transaction_time": "0",
> "proxy.process.http.icp_raw_transaction_time": "0",
> "proxy.process.http.parent_proxy_transaction_time": "0",
> "proxy.process.http.parent_proxy_raw_transaction_time": "0",
> 

[jira] [Comment Edited] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-2048 at 8/15/16 10:48 PM:
-

Leif's patch that won't compile:
{code}
diff --git a/iocore/cache/RamCacheCLFUS.cc b/iocore/cache/RamCacheCLFUS.cc
index 3f87532..bfce6a5 100644
--- a/iocore/cache/RamCacheCLFUS.cc
+++ b/iocore/cache/RamCacheCLFUS.cc
@@ -211,7 +211,9 @@ RamCacheCLFUS::init(int64_t abytes, Vol *avol)
   if (!max_bytes)
 return;
   resize_hashtable();
-  eventProcessor.schedule_every(new RamCacheCLFUSCompressor(this), 
HRTIME_SECOND, ET_TASK);
+  if (cache_config_ram_cache_compress) {
+eventProcessor.schedule_every(new RamCacheCLFUSCompressor(this), 
HRTIME_SECOND, ET_TASK);
+  }
 }
{code}


Now it compiles.


was (Author: bcall):
Leif's patch that won't compile:
{code}
diff --git a/iocore/cache/RamCacheCLFUS.cc b/iocore/cache/RamCacheCLFUS.cc
index 3f87532..bfce6a5 100644
--- a/iocore/cache/RamCacheCLFUS.cc
+++ b/iocore/cache/RamCacheCLFUS.cc
@@ -211,7 +211,9 @@ RamCacheCLFUS::init(int64_t abytes, Vol *avol)
   if (!max_bytes)
 return;
   resize_hashtable();
-  eventProcessor.schedule_every(new RamCacheCLFUSCompressor(this), 
HRTIME_SECOND, ET_TASK);
+  If (cache_config_ram_cache_compress) {
+eventProcessor.schedule_every(new RamCacheCLFUSCompressor(this), 
HRTIME_SECOND, ET_TASK);
+  }
 }
{code}

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[jira] [Commented] (TS-2134) SRV lookup does not handle failover correctly

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-2134:


[~jacksontj]
Has this be fixed?

> SRV lookup does not handle failover correctly
> -
>
> Key: TS-2134
> URL: https://issues.apache.org/jira/browse/TS-2134
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS, HTTP
>Reporter: Thach Tran
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 7.0.0
>
> Attachments: ats.log, ts2134.patch
>
>
> I'm seeing an issue with SRV lookup in ATS in which the proxy doesn't fail 
> over to alternative origins once the first choice is marked as down.
> To reproduce this, I'm running dnsmasq as a local resolver to serve up the 
> test SRV records. My configuration is as follows.
> h4. records.config
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING NULL
> CONFIG proxy.config.srv_enabled INT 1
> h4. remap.config
> regex_remap http://.*:8080/ https://noexample.com/
> h4. dnsmasq.conf (srv records config)
> srv-host=_http._tcp.noexample.com,abc.com,443,0,100
> srv-host=_http._tcp.noexample.com,google.com,443,1,100
> The intention is since the srv lookup for _http._tcp.noexample.com returns 
> abc.com:443 and google.com:443 with abc.com:443 being the one with higher 
> priority, the proxy should try that first and once the connection to 
> abc.com:443 is marked as down (up to 6 retries by default), google.com:443 
> should be tried next and the connection should succeed then.
> However, testing with the following curl command multiple times still gives 
> back 502.
> $ curl -v http://localhost:8080/
> Debug log seems to suggest it always attempts abc.com:443.



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

[jira] [Updated] (TS-2121) Log object memory leaks on startup

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2121:
---
Assignee: James Peach

> Log object memory leaks on startup
> --
>
> Key: TS-2121
> URL: https://issues.apache.org/jira/browse/TS-2121
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: James Peach
> Fix For: sometime
>
>
> After starting traffic_server, but not taking any traffic, there are some 
> logging-related memory leaks at startup:
> {code}
> Process: traffic_server [58701]
> Path:/opt/ats/bin/traffic_server
> Load Address:0x10bdc4000
> Identifier:  traffic_server
> Version: ??? (???)
> Code Type:   X86-64 (Native)
> Parent Process:  bash [48024]
> Date/Time:   2013-08-08 15:26:26.767 -0700
> OS Version:  Mac OS X 10.8.4 (12E55)
> Report Version:  7
> leaks Report Version:  2.0
> Process 58701: 12925 nodes malloced for 79092 KB
> Process 58701: 4 leaks for 368 total leaked bytes.
> Leak: 0x7ff265100110  size=144  zone: DefaultMallocZone_0x10c9c9000
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x0001 0x 0x651001a0 0x7ff2 ...e
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x0005 0x 0x 0x 
>   ...
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1570 
> | Log::init(int) Log.cc:983 | LogConfig::init(LogConfig*) LogConfig.cc:720 | 
> TextLogObject::TextLogObject(char const*, char const*, bool, char const*, 
> int, int, int, int) LogObject.cc:808 | TextLogObject::TextLogObject(char 
> const*, char const*, bool, char const*, int, int, int, int) LogObject.cc:807 
> | operator new(unsigned long) | malloc | malloc_zone_malloc 
> Leak: 0x7ff263408f50  size=112  zone: DefaultMallocZone_0x10c9c9000
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x 0x 0x4d555458 0x XTUM
>   0x 0x2060 0x 0x ` ..
>   0x 0x 0x 0x 
>   0x63408f90 0x7ff2 0x63408f94 0x7ff2 ..@c..@c
>   0x 0x 0x0005 0x 
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1351 
> | initialize_process_manager() Main.cc:364 | RecProcessInit(RecModeT, Diags*) 
> RecProcess.cc:375 | RecCoreInit(RecModeT, Diags*) RecCore.cc:165 | 
> RecConfigFileInit() RecConfigParse.cc:46 | create_queue() llqueue.cc:77 | 
> ats_malloc ink_memory.cc:50 | malloc | malloc_zone_malloc 
> Leak: 0x7ff263408fc0  size=96  zone: DefaultMallocZone_0x10c9c9000
>   0x63408fc8 0x7ff2 0x 0x ..@c
>   0x 0x 0x 0x 
>   0x 0x 0x0004 0x 
>   0x000c 0x001c 0x0003 0x 
>   0x0ca87069 0x0001 0x0ca87075 0x0001 ip..up..
>   0x 0x 0x 0x 
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1351 
> | initialize_process_manager() Main.cc:364 | RecProcessInit(RecModeT, Diags*) 
> RecProcess.cc:375 | RecCoreInit(RecModeT, Diags*) RecCore.cc:165 | 
> RecConfigFileInit() RecConfigParse.cc:47 | ink_hash_table_create 
> ink_hash_table.cc:62 | ats_malloc ink_memory.cc:50 | malloc | 
> malloc_zone_malloc 
> Leak: 0x7ff2651001a0  size=16  zone: DefaultMallocZone_0x10c9c9000  "text"
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1570 
> | Log::init(int) Log.cc:983 | LogConfig::init(LogConfig*) LogConfig.cc:720 | 
> TextLogObject::TextLogObject(char const*, char const*, bool, char const*, 
> int, int, int, int) LogObject.cc:808 | TextLogObject::TextLogObject(char 
> const*, char const*, bool, char const*, int, int, int, int) LogObject.cc:807 
> | LogFormat::LogFormat(LogFormatType) LogFormat.cc:228 | 
> LogFormat::LogFormat(LogFormatType) LogFormat.cc:220 | _xstrdup(char const*, 
> int, char const*) ink_resource.cc:45 | ats_malloc ink_memory.cc:50 | malloc | 
> malloc_zone_malloc 
> Binary Images:
>0x10bdc4000 -0x10c117ff7 +traffic_server (??? - ???) 
>  

[jira] [Updated] (TS-2121) Log object memory leaks on startup

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2121:
---
Summary: Log object memory leaks on startup  (was: log object memory leaks 
on startup)

> Log object memory leaks on startup
> --
>
> Key: TS-2121
> URL: https://issues.apache.org/jira/browse/TS-2121
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
> Fix For: sometime
>
>
> After starting traffic_server, but not taking any traffic, there are some 
> logging-related memory leaks at startup:
> {code}
> Process: traffic_server [58701]
> Path:/opt/ats/bin/traffic_server
> Load Address:0x10bdc4000
> Identifier:  traffic_server
> Version: ??? (???)
> Code Type:   X86-64 (Native)
> Parent Process:  bash [48024]
> Date/Time:   2013-08-08 15:26:26.767 -0700
> OS Version:  Mac OS X 10.8.4 (12E55)
> Report Version:  7
> leaks Report Version:  2.0
> Process 58701: 12925 nodes malloced for 79092 KB
> Process 58701: 4 leaks for 368 total leaked bytes.
> Leak: 0x7ff265100110  size=144  zone: DefaultMallocZone_0x10c9c9000
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x0001 0x 0x651001a0 0x7ff2 ...e
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x0005 0x 0x 0x 
>   ...
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1570 
> | Log::init(int) Log.cc:983 | LogConfig::init(LogConfig*) LogConfig.cc:720 | 
> TextLogObject::TextLogObject(char const*, char const*, bool, char const*, 
> int, int, int, int) LogObject.cc:808 | TextLogObject::TextLogObject(char 
> const*, char const*, bool, char const*, int, int, int, int) LogObject.cc:807 
> | operator new(unsigned long) | malloc | malloc_zone_malloc 
> Leak: 0x7ff263408f50  size=112  zone: DefaultMallocZone_0x10c9c9000
>   0x 0x 0x 0x 
>   0x 0x 0x 0x 
>   0x 0x 0x4d555458 0x XTUM
>   0x 0x2060 0x 0x ` ..
>   0x 0x 0x 0x 
>   0x63408f90 0x7ff2 0x63408f94 0x7ff2 ..@c..@c
>   0x 0x 0x0005 0x 
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1351 
> | initialize_process_manager() Main.cc:364 | RecProcessInit(RecModeT, Diags*) 
> RecProcess.cc:375 | RecCoreInit(RecModeT, Diags*) RecCore.cc:165 | 
> RecConfigFileInit() RecConfigParse.cc:46 | create_queue() llqueue.cc:77 | 
> ats_malloc ink_memory.cc:50 | malloc | malloc_zone_malloc 
> Leak: 0x7ff263408fc0  size=96  zone: DefaultMallocZone_0x10c9c9000
>   0x63408fc8 0x7ff2 0x 0x ..@c
>   0x 0x 0x 0x 
>   0x 0x 0x0004 0x 
>   0x000c 0x001c 0x0003 0x 
>   0x0ca87069 0x0001 0x0ca87075 0x0001 ip..up..
>   0x 0x 0x 0x 
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1351 
> | initialize_process_manager() Main.cc:364 | RecProcessInit(RecModeT, Diags*) 
> RecProcess.cc:375 | RecCoreInit(RecModeT, Diags*) RecCore.cc:165 | 
> RecConfigFileInit() RecConfigParse.cc:47 | ink_hash_table_create 
> ink_hash_table.cc:62 | ats_malloc ink_memory.cc:50 | malloc | 
> malloc_zone_malloc 
> Leak: 0x7ff2651001a0  size=16  zone: DefaultMallocZone_0x10c9c9000  "text"
>   Call stack: [thread 0x7fff7c782180]: | 0x1 | start | main Main.cc:1570 
> | Log::init(int) Log.cc:983 | LogConfig::init(LogConfig*) LogConfig.cc:720 | 
> TextLogObject::TextLogObject(char const*, char const*, bool, char const*, 
> int, int, int, int) LogObject.cc:808 | TextLogObject::TextLogObject(char 
> const*, char const*, bool, char const*, int, int, int, int) LogObject.cc:807 
> | LogFormat::LogFormat(LogFormatType) LogFormat.cc:228 | 
> LogFormat::LogFormat(LogFormatType) LogFormat.cc:220 | _xstrdup(char const*, 
> int, char const*) ink_resource.cc:45 | ats_malloc ink_memory.cc:50 | malloc | 
> malloc_zone_malloc 
> Binary Images:
>0x10bdc4000 -0x10c117ff7 +traffic_server 

[jira] [Closed] (TS-2101) Segmentation fault collation log server

[Bryan Call (JIRA)]

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

Bryan Call closed TS-2101.
--
   Resolution: Cannot Reproduce
Fix Version/s: (was: sometime)

Please reopen if this is an issue.

> Segmentation fault  collation log server
> 
>
> Key: TS-2101
> URL: https://issues.apache.org/jira/browse/TS-2101
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: bettydramit
>  Labels: crash
>
> gitmaster centos 6 x86_64
> {code}
> zym@zymtest1 /tmp $ c++filt < c
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b324c3a5500]
> /usr/bin/traffic_server(LogObjectManager::get_object_with_signature(unsigned 
> long)+0x24)[0x5a28e4]
> /usr/bin/traffic_server(Log::match_logobject(LogBufferHeader*)+0x3b)[0x58b98b]
> /usr/bin/traffic_server(LogCollationHostSM::host_recv(int, 
> void*)+0x1e0)[0x5ad940]
> /usr/bin/traffic_server[0x671291]
> /usr/bin/traffic_server[0x673f8a]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66c422]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x696b64]
> /usr/bin/traffic_server(EThread::execute()+0x4bb)[0x69754b]
> /usr/bin/traffic_server[0x695ae2]
> /lib64/libpthread.so.0(+0x7851)[0x2b324c39d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b324ea2f11d]
> {code}



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

[jira] [Issue Comment Deleted] (TS-2101) Segmentation fault collation log server

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2101:
--
Comment: was deleted

(was: Removing log collation feature.)

> Segmentation fault  collation log server
> 
>
> Key: TS-2101
> URL: https://issues.apache.org/jira/browse/TS-2101
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: bettydramit
>  Labels: crash
> Fix For: sometime
>
>
> gitmaster centos 6 x86_64
> {code}
> zym@zymtest1 /tmp $ c++filt < c
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b324c3a5500]
> /usr/bin/traffic_server(LogObjectManager::get_object_with_signature(unsigned 
> long)+0x24)[0x5a28e4]
> /usr/bin/traffic_server(Log::match_logobject(LogBufferHeader*)+0x3b)[0x58b98b]
> /usr/bin/traffic_server(LogCollationHostSM::host_recv(int, 
> void*)+0x1e0)[0x5ad940]
> /usr/bin/traffic_server[0x671291]
> /usr/bin/traffic_server[0x673f8a]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66c422]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x696b64]
> /usr/bin/traffic_server(EThread::execute()+0x4bb)[0x69754b]
> /usr/bin/traffic_server[0x695ae2]
> /lib64/libpthread.so.0(+0x7851)[0x2b324c39d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b324ea2f11d]
> {code}



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

[jira] [Issue Comment Deleted] (TS-2062) LogHost orphaned log does not honor log-buffer configs

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2062:
--
Comment: was deleted

(was: Removing the log collation feature.)

> LogHost orphaned log does not honor log-buffer configs
> --
>
> Key: TS-2062
> URL: https://issues.apache.org/jira/browse/TS-2062
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: Leif Hedstrom
>  Labels: A
> Fix For: sometime
>
>
> It looks like when we setup remote logging, the LogHost orphan log is always 
> created with the default configurations (9216 bytes). This ignores e.g.
> {code}
> proxy.config.log.log_buffer_size
> proxy.config.log.max_line_size
> {code}



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

[jira] [Updated] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2048:
---
Fix Version/s: (was: sometime)
   7.0.0

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[jira] [Updated] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2048:
---
Assignee: Leif Hedstrom

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 7.0.0
>
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[jira] [Commented] (TS-2048) Only schedule RamCacheCLFUSCompressor if feature is enabled

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-2048:


Leif's patch that won't compile:
{code}
diff --git a/iocore/cache/RamCacheCLFUS.cc b/iocore/cache/RamCacheCLFUS.cc
index 3f87532..bfce6a5 100644
--- a/iocore/cache/RamCacheCLFUS.cc
+++ b/iocore/cache/RamCacheCLFUS.cc
@@ -211,7 +211,9 @@ RamCacheCLFUS::init(int64_t abytes, Vol *avol)
   if (!max_bytes)
 return;
   resize_hashtable();
-  eventProcessor.schedule_every(new RamCacheCLFUSCompressor(this), 
HRTIME_SECOND, ET_TASK);
+  If (cache_config_ram_cache_compress) {
+eventProcessor.schedule_every(new RamCacheCLFUSCompressor(this), 
HRTIME_SECOND, ET_TASK);
+  }
 }
{code}

> Only schedule RamCacheCLFUSCompressor if feature is enabled
> ---
>
> Key: TS-2048
> URL: https://issues.apache.org/jira/browse/TS-2048
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Priority: Minor
> Fix For: sometime
>
>
> To do this we need to be able to schedule it if the feature is subsequently 
> enabled via traffic_line -x and also need to store the Event so that we can 
> disable it if it's disabled via traffic_line -x.



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

[jira] [Updated] (TS-2038) Add CoAdvisor automation in our CI

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2038:
---
Assignee: Leif Hedstrom

> Add CoAdvisor automation in our CI
> --
>
> Key: TS-2038
> URL: https://issues.apache.org/jira/browse/TS-2038
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Tests
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: Infrastructure
>
>




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

[jira] [Updated] (TS-2020) Add check to evacuation code to do RAM cache lookup and evacuate on a hit

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2020:
---
Fix Version/s: (was: sometime)
   7.2.0

> Add check to evacuation code to do RAM cache lookup and evacuate on a hit
> -
>
> Key: TS-2020
> URL: https://issues.apache.org/jira/browse/TS-2020
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: C, newbie
> Fix For: 7.2.0
>
>
> This will allow us to keep hotter items in the disk cache longer. It's not a 
> full LRU but it's cheap and will help.



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

[jira] [Updated] (TS-2020) Add check to evacuation code to do RAM cache lookup and evacuate on a hit

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2020:
---
Assignee: Phil Sorber

> Add check to evacuation code to do RAM cache lookup and evacuate on a hit
> -
>
> Key: TS-2020
> URL: https://issues.apache.org/jira/browse/TS-2020
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: C, newbie
> Fix For: 7.2.0
>
>
> This will allow us to keep hotter items in the disk cache longer. It's not a 
> full LRU but it's cheap and will help.



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

[jira] [Updated] (TS-2017) DNS lookups stop for a period after ATS receives a response it was not expecting

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2017:
---
Assignee: Alan M. Carroll  (was: Phil Sorber)

> DNS lookups stop for a period after ATS receives a response it was not 
> expecting
> 
>
> Key: TS-2017
> URL: https://issues.apache.org/jira/browse/TS-2017
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Phil Sorber
>Assignee: Alan M. Carroll
>  Labels: A, C
> Fix For: 7.1.0
>
>
> This stops all lookups for an observed 20 seconds which means no requests are 
> satisfied.



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

[jira] [Comment Edited] (TS-2025) HTTP Violation: caches must attach a Warning (113) if hit is older than 24h

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-2025 at 8/15/16 10:32 PM:
--

Updated RFC: https://tools.ietf.org/html/rfc7234#section-5.5.4

{noformat}
5.5.4.  Warning: 113 - "Heuristic Expiration"

   A cache SHOULD generate this if it heuristically chose a freshness
   lifetime greater than 24 hours and the response's age is greater than
   24 hours.
{noformat}


was (Author: bcall):
Updated RFC: https://tools.ietf.org/html/rfc7234#section-5.5.4

{code}
5.5.4.  Warning: 113 - "Heuristic Expiration"

   A cache SHOULD generate this if it heuristically chose a freshness
   lifetime greater than 24 hours and the response's age is greater than
   24 hours.
{code}

> HTTP Violation: caches must attach a Warning (113) if hit is older than 24h
> ---
>
> Key: TS-2025
> URL: https://issues.apache.org/jira/browse/TS-2025
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Igor Galić
>  Labels: newbie
> Fix For: sometime
>
>
> reference: https://tools.ietf.org/html/rfc2616#section-14.46
> To quote the RFC:
> {quote}
>113 Heuristic expiration
>  MUST be included if the cache heuristically chose a freshness
>  lifetime greater than 24 hours and the response's age is greater
>  than 24 hours.
> {quote}
> HTTPbis downgrades this to a "SHOULD": 
> https://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22#section-7.5.4
> {quote}
> 7.5.4. 113 Heuristic Expiration
>A cache SHOULD generate this if it heuristically chose a freshness
>lifetime greater than 24 hours and the response's age is greater than
>24 hours.
> {quote}



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

[jira] [Comment Edited] (TS-2025) HTTP Violation: caches must attach a Warning (113) if hit is older than 24h

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-2025 at 8/15/16 10:30 PM:
--

Updated RFC: https://tools.ietf.org/html/rfc7234#section-5.5.4

{code}
5.5.4.  Warning: 113 - "Heuristic Expiration"

   A cache SHOULD generate this if it heuristically chose a freshness
   lifetime greater than 24 hours and the response's age is greater than
   24 hours.
{code}


was (Author: bcall):
Updated RFC: https://tools.ietf.org/html/rfc7234#section-5.5.4

> HTTP Violation: caches must attach a Warning (113) if hit is older than 24h
> ---
>
> Key: TS-2025
> URL: https://issues.apache.org/jira/browse/TS-2025
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Igor Galić
>  Labels: newbie
> Fix For: sometime
>
>
> reference: https://tools.ietf.org/html/rfc2616#section-14.46
> To quote the RFC:
> {quote}
>113 Heuristic expiration
>  MUST be included if the cache heuristically chose a freshness
>  lifetime greater than 24 hours and the response's age is greater
>  than 24 hours.
> {quote}
> HTTPbis downgrades this to a "SHOULD": 
> https://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22#section-7.5.4
> {quote}
> 7.5.4. 113 Heuristic Expiration
>A cache SHOULD generate this if it heuristically chose a freshness
>lifetime greater than 24 hours and the response's age is greater than
>24 hours.
> {quote}



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

[jira] [Commented] (TS-2025) HTTP Violation: caches must attach a Warning (113) if hit is older than 24h

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-2025:


Updated RFC: https://tools.ietf.org/html/rfc7234#section-5.5.4

> HTTP Violation: caches must attach a Warning (113) if hit is older than 24h
> ---
>
> Key: TS-2025
> URL: https://issues.apache.org/jira/browse/TS-2025
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Igor Galić
>  Labels: newbie
> Fix For: sometime
>
>
> reference: https://tools.ietf.org/html/rfc2616#section-14.46
> To quote the RFC:
> {quote}
>113 Heuristic expiration
>  MUST be included if the cache heuristically chose a freshness
>  lifetime greater than 24 hours and the response's age is greater
>  than 24 hours.
> {quote}
> HTTPbis downgrades this to a "SHOULD": 
> https://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-22#section-7.5.4
> {quote}
> 7.5.4. 113 Heuristic Expiration
>A cache SHOULD generate this if it heuristically chose a freshness
>lifetime greater than 24 hours and the response's age is greater than
>24 hours.
> {quote}



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

[jira] [Updated] (TS-2017) DNS lookups stop for a period after ATS receives a response it was not expecting

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2017:
---
Assignee: Phil Sorber  (was: Thomas Jackson)

> DNS lookups stop for a period after ATS receives a response it was not 
> expecting
> 
>
> Key: TS-2017
> URL: https://issues.apache.org/jira/browse/TS-2017
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: A, C
> Fix For: 7.1.0
>
>
> This stops all lookups for an observed 20 seconds which means no requests are 
> satisfied.



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

[jira] [Updated] (TS-1996) Remove TSHttpTxnNewCacheLookupDo API

[Bryan Call (JIRA)]

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

Bryan Call updated TS-1996:
---
Fix Version/s: (was: sometime)
   8.0.0

> Remove TSHttpTxnNewCacheLookupDo API
> 
>
> Key: TS-1996
> URL: https://issues.apache.org/jira/browse/TS-1996
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: TS API
>Reporter: Leif Hedstrom
>  Labels: api-change, incompatible
> Fix For: 8.0.0
>
>




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