[GitHub] trafficserver issue #1630: ATS Lua could support shared dictionary just like...
GitHub user scw00 opened an issue: https://github.com/apache/trafficserver/issues/1630 ATS Lua could support shared dictionary just like nginx To replace nginx, ATS Lua could support shared dictionary just like nginx. --- 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 #1629: Assertion in state_read_server_response_he...
GitHub user scw00 opened a pull request: https://github.com/apache/trafficserver/pull/1629 Assertion in state_read_server_response_header (v7.1.0) In my opinion, the EPOLLERR always with read.enabled or write.enabled(otherwise, there is no sm could handle this event, we just ignore). So when EPOLLERR happens, we could push the vc into read_ready_list if the read.enabled == 1, otherwise push it into write_ready_list. You can merge this pull request into a Git repository by running: $ git pull https://github.com/scw00/ats-self TS_1531 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1629.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 #1629 commit 732e7d9fb8e4a717bc53de464d33f3ce666eaaf4 Author: scw00 <616955...@qq.com> Date: 2017-04-03T11:29:02Z TS_1531 commit a968e80993fba38b3c4e80d8c469b34b306fda7f Author: scw00 <616955...@qq.com> Date: 2017-04-03T13:51:08Z TS_1531 --- 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 #1628: Assertion in state_read_server_response_he...
Github user scw00 closed the pull request at: https://github.com/apache/trafficserver/pull/1628 --- 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 #1628: Assertion in state_read_server_response_he...
GitHub user scw00 opened a pull request: https://github.com/apache/trafficserver/pull/1628 Assertion in state_read_server_response_header (v7.1.0) In my opinion, the EPOLLERR always with read.enabled or write.enabled(otherwise, there is no sm could handle this event, we just ignore). So when EPOLLERR happens, we could push the vc into read_ready_list if the read.enabled == 1, otherwise push it into write_ready_list. You can merge this pull request into a Git repository by running: $ git pull https://github.com/scw00/ats-self TS_1531 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1628.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 #1628 commit 732e7d9fb8e4a717bc53de464d33f3ce666eaaf4 Author: scw00 <616955...@qq.com> Date: 2017-04-03T11:29:02Z TS_1531 --- 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 #1531: Assertion in state_read_server_response_header (v...
Github user scw00 commented on the issue:
https://github.com/apache/trafficserver/issues/1531
There are reasons for this creash:
1ãATS try to connect the origin server, but receive RST package. So ATS
try again until retry_times == 0. It will clean the server_entry (mark the VC
as closed, remove this VC from write_ready_list and read_ready_list, then close
it) in every times except the last one(It is easy to re-product), so it will
call both read sm and write sm in the last times, and the write sm causes crash.
2ãEpoll trigger EPOLLERR without EVENTIO_READ(hard to re-product).
In my opinion, the EPOLLERR always with read.enabled or
write.enabled(otherwise, there is no sm could handle this event, we just
ignore). So when EPOLLERR happens, we could push the vc into read_ready_list if
the read.enabled == 1, otherwise push it into write_ready_list.
By the way, there is my program to re-product this crash:
```
package main
import (
"net"
"os"
"fmt"
)
func main() {
ls, err := net.Listen("tcp", os.Args[1])
if err != nil {
fmt.Println(err)
os.Exit(1)
}
for {
conn, err := ls.Accept()
if err != nil {
fmt.Println(err)
os.Exit(1)
}
go handleConnection(conn)
}
}
func handleConnection(con net.Conn) {
con.Close()
}
```
---
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 #1625: HttpSM::state_cache_open_write crash
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/issues/1625 version? --- 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 #1559: Do not callback one SM EVENT_ERROR twice.
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1559 @oknet I it work well on my test env, and jtest can not re-product any more ! --- 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 #1531: Assertion in state_read_server_response_header (v...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/issues/1531 Based on #1522 we need to ensure that all the handler should handle read error event and write error event at same time. I'll track 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. ---
[GitHub] trafficserver issue #1522: Ignore read and write errors if vio has been clea...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1522 Agree!! --- 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 #1522: Ignore read and write errors if vio has been clea...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1522 I believe all of these issue have the same reason. the reproduct is easy. Run jtest and press Control + C, repeat until you see this assert. I think, if we merge this pr, that means every handler should handle write event and read event. it may cause chaos! Reverting may not be a good choice,but it really avoids this situation! By the way! I approve oknet's opinion, he hope we could set a special handler to collect this error event . --- 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 #1544: AddressSanitizer failed to deallocate
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/issues/1544 7.1.0 --- 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 #1544: AddressSanitizer failed to deallocate
GitHub user scw00 opened an issue:
https://github.com/apache/trafficserver/issues/1544
AddressSanitizer failed to deallocate
```
==22977== ERROR: AddressSanitizer failed to deallocate 0x23000 (143360)
bytes at address 0x7fff680d
==22977== AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:81 "(("unable
to unmap" && 0)) != (0)" (0x0, 0x0)
==22977== ERROR: AddressSanitizer failed to deallocate 0x8 (524288)
bytes at address 0x7fff67fc7000
==22977== AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:81 "(("unable
to unmap" && 0)) != (0)" (0x0, 0x0)
==22977== ERROR: AddressSanitizer failed to deallocate 0x20 (2097152)
bytes at address 0x7fff67da4000
==22977== AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:81 "(("unable
to unmap" && 0)) != (0)" (0x0, 0x0)
==22977== ERROR: AddressSanitizer failed to deallocate 0x10 (1048576)
bytes at address 0x7fff67c81000
==22977== AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:81 "(("unable
to unmap" && 0)) != (0)" (0x0, 0x0)
==22977== ERROR: AddressSanitizer failed to deallocate 0x4000 (16384) bytes
at address 0x77fdd000
==22977== AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:81 "(("unable
to unmap" && 0)) != (0)" (0x0, 0x0)
==22977== ERROR: AddressSanitizer failed to deallocate 0x23000 (143360)
bytes at address 0x7fff66f0
==22977== AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:81 "(("unable
to unmap" && 0)) != (0)" (0x0, 0x0)
```
---
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 #1522: Ignore read and write errors if vio has been clea...
Github user scw00 commented on the issue:
https://github.com/apache/trafficserver/pull/1522
```
(gdb) p *server_entry->read_vio
$3 = {_cont = 0x607000476100, nbytes = 9223372036854775807, ndone = 0, op =
1, buffer = {name = 0x0, mbuf = 0x6024000cebc0, entry = 0x0},
vc_server = 0x603c00270900, mutex = {m_ptr = 0x601800129ac0}}
(gdb) p (VIO *)data
$4 = (VIO *) 0x603c00270aa0
(gdb) p *(VIO *)data
$5 = {_cont = 0x607000476100, nbytes = 172, ndone = 172, op = 2, buffer =
{name = 0x0, mbuf = 0x6024000ce6c0, entry = 0x6024000ce6d8},
vc_server = 0x603c00270900, mutex = {m_ptr = 0x601800129ac0}}
(gdb)
```
---
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 #1532: ATS 7.1 release running out of memory
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/issues/1532 We have meet the same situation in our product env, and we try to modified max_map_count, the kernel variable, and it work well. In Short, it may too much map nnon in process, and linux limited it by max_map_count ! --- 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 #1522: Ignore read and write errors if vio has been clea...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1522 Actually, there is still a problem in my test after these patch by jtest. ``` #0 0x72be9c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x72bed028 in __GI_abort () at abort.c:89 #2 0x74bd8e55 in ink_abort (message_format=0x74c1da40 "%s:%d: failed assertion `%s`") at ink_error.cc:99 #3 0x74bd34bb in _ink_assert (expression=0xb13620 "server_entry->read_vio == (VIO *)data", file=0xb11420 "HttpSM.cc", line=1827) at ink_assert.cc:37 #4 0x0068e24e in HttpSM::state_read_server_response_header (this=0x60700016e100, event=3, data=0x603c0039d3a0) at HttpSM.cc:1827 #5 0x00695861 in HttpSM::main_handler (this=0x60700016e100, event=3, data=0x603c0039d3a0) at HttpSM.cc:2679 #6 0x00539f32 in Continuation::handleEvent (this=0x60700016e100, event=3, data=0x603c0039d3a0) at /root/ATS-7.0/trafficserver/iocore/eventsystem/I_Continuation.h:153 #7 0x00a2a2e0 in write_signal_and_update (event=3, vc=0x603c0039d200) at UnixNetVConnection.cc:176 #8 0x00a2a6b2 in write_signal_done (event=3, nh=0x7fffef217650, vc=0x603c0039d200) at UnixNetVConnection.cc:218 #9 0x00a2a7b8 in write_signal_error (nh=0x7fffef217650, vc=0x603c0039d200, lerrno=32) at UnixNetVConnection.cc:237 #10 0x00a2bf13 in write_to_net_io (nh=0x7fffef217650, vc=0x603c0039d200, thread=0x7fffef213800) at UnixNetVConnection.cc:453 #11 0x00a2bbe9 in write_to_net (nh=0x7fffef217650, vc=0x603c0039d200, thread=0x7fffef213800) at UnixNetVConnection.cc:430 #12 0x00a19be5 in NetHandler::mainNetEvent (this=0x7fffef217650, event=5, e=0x60125ab0) at UnixNet.cc:526 #13 0x00539f32 in Continuation::handleEvent (this=0x7fffef217650, event=5, data=0x60125ab0) at /root/ATS-7.0/trafficserver/iocore/eventsystem/I_Continuation.h:153 #14 0x00a764af in EThread::process_event (this=0x7fffef213800, e=0x60125ab0, calling_code=5) at UnixEThread.cc:143 #15 0x00a7713f in EThread::execute (this=0x7fffef213800) at UnixEThread.cc:270 #16 0x00a74dfc in spawn_thread_internal (a=0x600800015a50) at Thread.cc:84 #17 0x74e63b98 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0 #18 0x739a4184 in start_thread (arg=0x7fffe3d5a700) at pthread_create.c:312 #19 0x72cad37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 ``` We got the error event and callback to SM, but SM do not want to this write event.because write.enabled is 0. So SM assert! The backtrace is the same as #1531 . So I think if enabled is 0 , we should not callback to any SM. 6.0.x logic may be better! --- 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 #1522: Ignore read and write errors if vio has been clea...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1522 I think, it #never calls handler with read.enabled = 0(or write.enabled). It means the handler don not want this type of event .It may never handle this event and just assert! #1531 --- 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 #1531: Assertion in state_read_server_response_header (v...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/issues/1531 I think, it never call handler with read.enabled = 0(or write.enabled). It means the handler don not want this type of event .It may never handle this event and just assert! [https://github.com/apache/trafficserver/pull/1522](url) --- 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 #1401: Segfault in write_to_net_io with 7.1.x
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/issues/1401 epoll_wait trigger EVENTIO_ERROR(in read or write) would case segfault, because we do not set any state in vc(by calling do_io_xxx). we just recevie sockets and register in epoll_wait. In 6.x.x, we do not handle EVENTIO_ERROR. It may cause vc leaking, but avoid coredump. Calling do_io_xx before register or closed directly(it do not enter the trasaction) may fix it, but still on test. --- 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 #1401: Segfault in write_to_net_io with 7.1.x
Github user scw00 commented on the issue:
https://github.com/apache/trafficserver/issues/1401
epoll_wait triggered EVENTIO_ERROR after accept(do_blocking_accept) will
cause coredump, because we do not call any do_io_xx. In 6.x.x we do not handle
EVENTIO_ERROR eventï¼it may cause vc leaking, but avoid coredump.
` while ((vc = write_ready_list.dequeue())) {
set_cont_flags(vc->control_flags);
if (vc->closed)
close_UnixNetVConnection(vc, trigger_event->ethread);
else if ((vc->write.enabled || vc->write.error) && vc->write.triggered)
write_to_net(this, vc, trigger_event->ethread);
else if (!vc->write.enabled) {
write_ready_list.remove(vc);
#if defined(solaris)
if (vc->write.triggered && vc->read.enabled) {
vc->ep.modify(-EVENTIO_WRITE);
vc->ep.refresh(EVENTIO_READ);
vc->readReschedule(this);
}
#endif
}`
---
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 #1229: TS-5061 TS use ats_malloc instead of malloc in lo...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1229 Here is another one , Sorry! https://github.com/apache/trafficserver/pull/1249 --- 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 #1249: TS-5061 TS use ats_malloc instead of mallo...
GitHub user scw00 opened a pull request: https://github.com/apache/trafficserver/pull/1249 TS-5061 TS use ats_malloc instead of malloc in log module It should be abort immediately while malloc failed . So why do not use ats_malloc to instead of malloc? You can merge this pull request into a Git repository by running: $ git pull https://github.com/scw00/trafficserver master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1249.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 #1249 commit 8ae1b8ae97263bacd52edf46d3842ed00b85cfc9 Author: Song <616955...@qq.com> Date: 2016-12-06T02:47:10Z TS-5061 TS use ats_malloc instead of malloc in log module --- 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 #1229: TS-5061 TS use ats_malloc instead of malloc in lo...
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1229 ok --- 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 #1229: TS-5061 TS use ats_malloc instead of mallo...
GitHub user scw00 opened a pull request: https://github.com/apache/trafficserver/pull/1229 TS-5061 TS use ats_malloc instead of malloc in log module It should be abort immediately while malloc failed . So why do not use ats_malloc instead of malloc? You can merge this pull request into a Git repository by running: $ git pull https://github.com/scw00/trafficserver 7.0.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1229.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 #1229 commit 86eef601b984953f2e3d2b5c964367204f8afa6d Author: scw00 <616955...@qq.com> Date: 2016-11-21T10:29:08Z Update LogFile.cc --- 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 #1180: TS-4991 jtest should handle Range request
GitHub user scw00 opened a pull request: https://github.com/apache/trafficserver/pull/1180 TS-4991 jtest should handle Range request TS-4991 jtest should handle Range request Jtest will support random range by "--range_model 1" args. And it uses the dran48 to generate 2 numbers as the range boundary. Range size should be larger than 100 Bytes to contains the verified data(Although we do not verify this content ). You can merge this pull request into a Git repository by running: $ git pull https://github.com/scw00/trafficserver master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1180.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 #1180 commit adaa344a09fbbad1c8d95dca82d7da13e19cba84 Author: Song <616955...@qq.com> Date: 2016-11-03T00:55:29Z TS-4991 jtest should handle Range request --- 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 #1130: TS-4991 jtest should handle Range request
Github user scw00 closed the pull request at: https://github.com/apache/trafficserver/pull/1130 --- 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 #1130: TS-4991 jtest should handle Range request
Github user scw00 commented on the issue: https://github.com/apache/trafficserver/pull/1130 TS-4991 jtest should handle Range request Jtest will support random range by "--range_model 1" args. And it uses the dran48 to generate 2 numbers as the range boundary. Range size should be larger than 100 Bytes to contains the verified data(Although we do not verify this content ). --- 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 #1130: TS-4991 jtest should handle Range request
GitHub user scw00 opened a pull request: https://github.com/apache/trafficserver/pull/1130 TS-4991 jtest should handle Range request Jtest would support random range. You can merge this pull request into a Git repository by running: $ git pull https://github.com/scw00/trafficserver master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1130.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 #1130 commit 62ff9a6bc9728ced36645df384292e125262b1f9 Author: Your Name <y...@example.com> Date: 2016-10-21T08:04:02Z new feature jtest --- 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. ---
