[jira] [Created] (TS-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
Bin Chen created TS-2201: Summary: split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request Key: TS-2201 URL: https://issues.apache.org/jira/browse/TS-2201 Project: Traffic Server Issue Type: Improvement Components: Clustering, cop Reporter: Bin Chen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
[ https://issues.apache.org/jira/browse/TS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen reassigned TS-2201: Assignee: Bin Chen > split drainIncomingChannel two thread, one handle Broadcast message and other > handle Reliable(TCP) request > -- > > Key: TS-2201 > URL: https://issues.apache.org/jira/browse/TS-2201 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, cop >Reporter: Bin Chen >Assignee: Bin Chen > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2185) support to control ClusterCom::sendSharedData frequency
[ https://issues.apache.org/jira/browse/TS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762815#comment-13762815 ] ASF subversion and git services commented on TS-2185: - Commit 0a92bcdccec4e79e1527521a01f2a464a7d6ce28 in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0a92bcd ] TS-2185: support to control ClusterCom::sendSharedData frequency > support to control ClusterCom::sendSharedData frequency > --- > > Key: TS-2185 > URL: https://issues.apache.org/jira/browse/TS-2185 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-2185.patch > > > support to control ClusterCom::sendSharedData frequency. The original design > ClusterCom::sendSharedData will be called every loop. It's so frequent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-2185) support to control ClusterCom::sendSharedData frequency
[ https://issues.apache.org/jira/browse/TS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-2185. Resolution: Fixed Fix Version/s: 4.1.0 > support to control ClusterCom::sendSharedData frequency > --- > > Key: TS-2185 > URL: https://issues.apache.org/jira/browse/TS-2185 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.1.0 > > Attachments: TS-2185.patch > > > support to control ClusterCom::sendSharedData frequency. The original design > ClusterCom::sendSharedData will be called every loop. It's so frequent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762831#comment-13762831 ] ASF subversion and git services commented on TS-1637: - Commit cb9b0ffd8e9b4fb0f1b6909918abb2894eb76217 in branch refs/heads/master from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cb9b0ff ] TS-1637: Fix nodes as idle/dead if we have not heard from them in awhile > nodes as idle/dead if we have not heard from them in awhile > --- > > Key: TS-1637 > URL: https://issues.apache.org/jira/browse/TS-1637 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Management >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.2.0 > > Attachments: TS-1637.patch, TS-1637_v2.patch > > > in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer > node quickly(if timeout, will > 30s(default peer_timeout)), then won't send > Shared date called by ClusterCom::sendSharedData. So peer node will marking > me down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen closed TS-1637. Resolution: Fixed Fix Version/s: (was: 4.2.0) 4.1.0 > nodes as idle/dead if we have not heard from them in awhile > --- > > Key: TS-1637 > URL: https://issues.apache.org/jira/browse/TS-1637 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Management >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.1.0 > > Attachments: TS-1637.patch, TS-1637_v2.patch > > > in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer > node quickly(if timeout, will > 30s(default peer_timeout)), then won't send > Shared date called by ClusterCom::sendSharedData. So peer node will marking > me down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2201) split drainIncomingChannel two thread, one handle Broadcast message and other handle Reliable(TCP) request
[ https://issues.apache.org/jira/browse/TS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bin Chen updated TS-2201: - Attachment: TS-2201.patch > split drainIncomingChannel two thread, one handle Broadcast message and other > handle Reliable(TCP) request > -- > > Key: TS-2201 > URL: https://issues.apache.org/jira/browse/TS-2201 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, cop >Reporter: Bin Chen >Assignee: Bin Chen > Attachments: TS-2201.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2202) remove manager error and fatal useless errno and error message
Yu Qing created TS-2202: --- Summary: remove manager error and fatal useless errno and error message Key: TS-2202 URL: https://issues.apache.org/jira/browse/TS-2202 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Yu Qing we should log errno and strerror(errno) only when errno != 0. the errno parameter should pass by the caller. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2203) logcat should not act as a SAC server
Zhao Yongming created TS-2203:
-
Summary: logcat should not act as a SAC server
Key: TS-2203
URL: https://issues.apache.org/jira/browse/TS-2203
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Zhao Yongming
logcat will create some very strage log in the var log messages:
{code}
Sep 10 16:29:41 New traffic_logcat[20939]: NOTE: --- SAC Starting ---
Sep 10 16:29:41 New traffic_logcat[20939]: NOTE: SAC Version: Apache Traffic
Server - traffic_logcat - 4.0.1 - (build # 8323 on Sep 3 2013 at 23:11:29)
Sep 10 16:30:22 New traffic_logcat[21009]: NOTE: --- SAC Starting ---
Sep 10 16:30:22 New traffic_logcat[21009]: NOTE: SAC Version: Apache Traffic
Server - traffic_logcat - 4.0.1 - (build # 8323 on Sep 3 2013 at 23:11:29)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2202) remove manager error and fatal useless errno and error message
[ https://issues.apache.org/jira/browse/TS-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Qing updated TS-2202: Assignee: Yu Qing > remove manager error and fatal useless errno and error message > -- > > Key: TS-2202 > URL: https://issues.apache.org/jira/browse/TS-2202 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Yu Qing >Assignee: Yu Qing > > we should log errno and strerror(errno) only when errno != 0. > the errno parameter should pass by the caller. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2204) ts should not cache the response with unrecognized codes
Zhao Yongming created TS-2204: - Summary: ts should not cache the response with unrecognized codes Key: TS-2204 URL: https://issues.apache.org/jira/browse/TS-2204 Project: Traffic Server Issue Type: Bug Components: Cache, HTTP Reporter: Zhao Yongming according to RFC 2616: 6.1.1 HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status. and we should not cache any of the unknown response. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-2205:
--
Affects Version/s: 4.0.1
Fix Version/s: 4.1.0
Assignee: weijin
> AIO caused system hang
> --
>
> Key: TS-2205
> URL: https://issues.apache.org/jira/browse/TS-2205
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.0.1
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 4.1.0
>
>
> the system may hang with AIO thread CPU usage rising:
> {code}
> top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
> Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
> Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
> Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
> Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
> 3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
> 3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
> 4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
>13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
>37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
>45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
> 32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
> 32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
>25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
>65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
> 32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
> 32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
> 32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
> 32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
> 32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
> 32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
> 32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
> 32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
> 32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
> 32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
> 32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
> 32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
> 32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
> 32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2205) AIO caused system hang
Zhao Yongming created TS-2205:
-
Summary: AIO caused system hang
Key: TS-2205
URL: https://issues.apache.org/jira/browse/TS-2205
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Zhao Yongming
the system may hang with AIO thread CPU usage rising:
{code}
top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2203) logcat should not act as a SAC server
[
https://issues.apache.org/jira/browse/TS-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-2203:
--
Affects Version/s: 4.0.1
Fix Version/s: 4.1.0
> logcat should not act as a SAC server
> -
>
> Key: TS-2203
> URL: https://issues.apache.org/jira/browse/TS-2203
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 4.0.1
>Reporter: Zhao Yongming
> Fix For: 4.1.0
>
>
> logcat will create some very strage log in the var log messages:
> {code}
> Sep 10 16:29:41 New traffic_logcat[20939]: NOTE: --- SAC Starting ---
> Sep 10 16:29:41 New traffic_logcat[20939]: NOTE: SAC Version: Apache Traffic
> Server - traffic_logcat - 4.0.1 - (build # 8323 on Sep 3 2013 at 23:11:29)
> Sep 10 16:30:22 New traffic_logcat[21009]: NOTE: --- SAC Starting ---
> Sep 10 16:30:22 New traffic_logcat[21009]: NOTE: SAC Version: Apache Traffic
> Server - traffic_logcat - 4.0.1 - (build # 8323 on Sep 3 2013 at 23:11:29)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2187) failed assert `nr == sizeof(uint64_t)` in EventNotify::signal()
[
https://issues.apache.org/jira/browse/TS-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-2187:
--
Description:
I have noticed two bug report on "failed assert `nr == sizeof(uint64_t)`" in
EventNotify::signal():
{code}
[TrafficServer] using root directory '/usr/local/trafficserver-4.1.0'
FATAL: EventNotify.cc:73: failed assert `nr == sizeof(uint64_t)`
/usr/local/trafficserver-4.1.0/bin/traffic_server - STACK TRACE:
/usr/local/trafficserver-4.1.0/lib/libtsutil.so.4(+0x14b57)[0x2b71a2d84b57]
/usr/local/trafficserver-4.1.0/lib/libtsutil.so.4(+0x13d7f)[0x2b71a2d83d7f]
/usr/local/trafficserver-4.1.0/lib/libtsutil.so.4(+0x1c32e)[0x2b71a2d8c32e]
/usr/local/trafficserver-4.1.0/bin/traffic_server(LogObject::_checkout_write(unsigned
long*, unsigned long)+0x1f5)[0x5adf25]
/usr/local/trafficserver-4.1.0/bin/traffic_server(LogObjectManager::check_buffer_expiration(long)+0x7b)[0x5afbfb]
/usr/local/trafficserver-4.1.0/bin/traffic_server(Log::periodic_tasks(long)+0xe2)[0x595c92]
/usr/local/trafficserver-4.1.0/bin/traffic_server(Log::flush_thread_main(void*)+0x28e)[0x596cee]
/usr/local/trafficserver-4.1.0/bin/traffic_server[0x59abcd]
/usr/local/trafficserver-4.1.0/bin/traffic_server(EThread::execute()+0x1159)[0x6ae139]
/usr/local/trafficserver-4.1.0/bin/traffic_server[0x6ab93a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x2b71a479cb50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b71a5430a7d]
[E. Mgmt] log ==> [TrafficManager] using root directory
'/usr/local/trafficserver-4.1.0'
[TrafficServer] using root directory '/usr/local/trafficserver-4.1.0'
{code}
In order to fix this issue, I cook a patch:
1) Use nonblock eventfd, so that we can tolerate write() failed with errno
EAGAIN -- which is acceptable as the signal receiver will be notified
eventually in this case.
2) After using nonblock eventfd, read() will not block in wait(). So I use
epoll_wait() to implement block behavior, just like timedwait().
3) nonblock eventfd can fix a potential problem: if receiver didn't read() data
immediately, senders might block in write().
Please test this patch, any feedback is welcome.
was:
I have noticed two bug report on "failed assert `nr == sizeof(uint64_t)`" in
EventNotify::signal():
{code}
[TrafficServer] using root directory '/usr/local/trafficserver-4.1.0'
FATAL: EventNotify.cc:73: failed assert `nr == sizeof(uint64_t)`
/usr/local/trafficserver-4.1.0/bin/traffic_server - STACK TRACE:
/usr/local/trafficserver-4.1.0/lib/libtsutil.so.4(+0x14b57)[0x2b71a2d84b57]
/usr/local/trafficserver-4.1.0/lib/libtsutil.so.4(+0x13d7f)[0x2b71a2d83d7f]
/usr/local/trafficserver-4.1.0/lib/libtsutil.so.4(+0x1c32e)[0x2b71a2d8c32e]
/usr/local/trafficserver-4.1.0/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0x1f5)[0x5adf25]
/usr/local/trafficserver-4.1.0/bin/traffic_server(_ZN16LogObjectManager23check_buffer_expirationEl+0x7b)[0x5afbfb]
/usr/local/trafficserver-4.1.0/bin/traffic_server(_ZN3Log14periodic_tasksEl+0xe2)[0x595c92]
/usr/local/trafficserver-4.1.0/bin/traffic_server(_ZN3Log17flush_thread_mainEPv+0x28e)[0x596cee]
/usr/local/trafficserver-4.1.0/bin/traffic_server[0x59abcd]
/usr/local/trafficserver-4.1.0/bin/traffic_server(_ZN7EThread7executeEv+0x1159)[0x6ae139]
/usr/local/trafficserver-4.1.0/bin/traffic_server[0x6ab93a]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50)[0x2b71a479cb50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b71a5430a7d]
[E. Mgmt] log ==> [TrafficManager] using root directory
'/usr/local/trafficserver-4.1.0'
[TrafficServer] using root directory '/usr/local/trafficserver-4.1.0'
{code}
In order to fix this issue, I cook a patch:
1) Use nonblock eventfd, so that we can tolerate write() failed with errno
EAGAIN -- which is acceptable as the signal receiver will be notified
eventually in this case.
2) After using nonblock eventfd, read() will not block in wait(). So I use
epoll_wait() to implement block behavior, just like timedwait().
3) nonblock eventfd can fix a potential problem: if receiver didn't read() data
immediately, senders might block in write().
Please test this patch, any feedback is welcome.
> failed assert `nr == sizeof(uint64_t)` in EventNotify::signal()
> ---
>
> Key: TS-2187
> URL: https://issues.apache.org/jira/browse/TS-2187
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.1.0
>
> Attachments: 0001-TS-2187-use-nonblock-eventfd-in-EventNotify.patch
>
>
> I have noticed two bug report on "failed assert `nr == sizeof(uint64_t)`" in
> EventNotify::signal():
> {code}
> [TrafficServer] using root directory '/usr/local/trafficserver-4.1.0'
> FATAL: EventNotify.cc:73: failed assert `nr == sizeof(uint64_t)`
> /usr/local/trafficserver-4.1.0/bin
[jira] [Commented] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762922#comment-13762922
]
Zhao Yongming commented on TS-2205:
---
this is a issue reported from ShangHai Jiao Tong Univercity
http://www.sjtu.edu.cn/
> AIO caused system hang
> --
>
> Key: TS-2205
> URL: https://issues.apache.org/jira/browse/TS-2205
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.0.1
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 4.1.0
>
>
> the system may hang with AIO thread CPU usage rising:
> {code}
> top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
> Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
> Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
> Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
> Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
> 3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
> 3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
> 4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
>13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
>37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
>45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
> 32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
> 32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
>25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
>65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
> 32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
> 32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
> 32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
> 32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
> 32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
> 32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
> 32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
> 32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
> 32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
> 32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
> 32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
> 32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
> 32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
> 32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1695) test_certlookup fails on FreeBSD 10
[
https://issues.apache.org/jira/browse/TS-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763003#comment-13763003
]
Igor Galić commented on TS-1695:
I've looked into this a bit more and I've decided that given the low maturity
of FreeBSD 10 (it's still heavily in development:
https://wiki.freebsd.org/FreeBSD10 ) we should probably focus on something
that's closer to reality, namely FreeBSD 9.2:
http://www.freebsd.org/releases/9.2R/schedule.html
For now, we can close this bug as invalid/cannot repro.
> test_certlookup fails on FreeBSD 10
> ---
>
> Key: TS-1695
> URL: https://issues.apache.org/jira/browse/TS-1695
> Project: Traffic Server
> Issue Type: Bug
> Components: Portability
> Environment: FreeBSD 10, amd64
>Reporter: Igor Galić
>Assignee: Igor Galić
> Labels: freebsd
> Fix For: 4.2.0
>
>
> {noformat}
> Reading symbols from
> /tmp/org.apache.trafficserver.2624/obj/iocore/net/.libs/test_certlookup...done.
> [New process 100244]
> [New Thread 803806400 (LWP 100244)]
> Core was generated by `test_certlookup'.
> Program terminated with signal 10, Bus error.
> #0 0x000802cbc43b in ?? () from /lib/libc.so.7
> (gdb) bt
> #0 0x000802cbc43b in ?? () from /lib/libc.so.7
> #1 0x000802cc8c74 in free () from /lib/libc.so.7
> #2 0x00405ca6 in Trie::Clear
> (this=0x80382c800) at /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:213
> #3 0x00405d21 in Trie::~Trie
> (this=0x80382c800, __in_chrg=) at
> /home/igalic/src/asf/trafficserver/lib/ts/Trie.h:54
> #4 0x00403c11 in SSLContextStorage::~SSLContextStorage
> (this=0x80382c800, __in_chrg=) at
> /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:213
> #5 0x00403d05 in SSLCertLookup::~SSLCertLookup (this=0x7fffd2e0,
> __in_chrg=) at
> /home/igalic/src/asf/trafficserver/iocore/net/SSLCertLookup.cc:102
> #6 0x004036a8 in RegressionTest_SSLCertificateLookup (t=0x60daa0
> , atype=0, pstatus=0x60dab8
> )
> at /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:78
> #7 0x00080085eff6 in start_test (t=0x60daa0
> ) at
> /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:77
> #8 0x00080085f404 in RegressionTest::run (atest=0x0) at
> /home/igalic/src/asf/trafficserver/lib/ts/Regression.cc:98
> #9 0x00402ce0 in main (argc=1, argv=0x7fffd470) at
> /home/igalic/src/asf/trafficserver/iocore/net/test_certlookup.cc:197
> (gdb)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2205) AIO caused system hang
[
https://issues.apache.org/jira/browse/TS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-2205:
--
Priority: Critical (was: Major)
> AIO caused system hang
> --
>
> Key: TS-2205
> URL: https://issues.apache.org/jira/browse/TS-2205
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.0.1
>Reporter: Zhao Yongming
>Assignee: weijin
>Priority: Critical
> Fix For: 4.1.0
>
>
> the system may hang with AIO thread CPU usage rising:
> {code}
> top - 17:10:46 up 38 days, 22:43, 2 users, load average: 11.34, 2.97, 2.75
> Tasks: 512 total, 55 running, 457 sleeping, 0 stopped, 0 zombie
> Cpu(s): 6.9%us, 54.8%sy, 0.0%ni, 37.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st
> Mem: 65963696k total, 64318444k used, 1645252k free, 241496k buffers
> Swap: 33554424k total,20416k used, 33534008k free, 14864188k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 32498 ats 20 0 59.3g 45g 25m R 65.8 72.1 24:44.15 [ET_AIO 5]
> 3213 root 20 0 000 S 15.4 0.0 13:38.32 kondemand/7
> 3219 root 20 0 000 S 15.1 0.0 16:32.78 kondemand/13
> 4 root 20 0 000 S 13.8 0.0 33:18.13 ksoftirqd/0
>13 root 20 0 000 S 13.4 0.0 21:45.18 ksoftirqd/2
>37 root 20 0 000 S 13.4 0.0 19:42.34 ksoftirqd/8
>45 root 20 0 000 S 13.4 0.0 18:31.17 ksoftirqd/10
> 32483 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:47.14 [ET_AIO 6]
> 32487 ats 20 0 59.3g 45g 25m R 13.4 72.1 16:46.93 [ET_AIO 2]
>25 root 20 0 000 S 13.1 0.0 19:02.18 ksoftirqd/5
>65 root 20 0 000 S 13.1 0.0 19:24.04 ksoftirqd/15
> 32477 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:32.90 [ET_AIO 0]
> 32478 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:49.77 [ET_AIO 1]
> 32479 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:41.77 [ET_AIO 2]
> 32481 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:50.40 [ET_AIO 4]
> 32482 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:47.42 [ET_AIO 5]
> 32484 ats 20 0 59.3g 45g 25m R 13.1 72.1 16:25.81 [ET_AIO 7]
> 32485 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:52.71 [ET_AIO 0]
> 32486 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:51.69 [ET_AIO 1]
> 32491 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:50.58 [ET_AIO 6]
> 32492 ats 20 0 59.3g 45g 25m S 13.1 72.1 16:49.12 [ET_AIO 7]
> 32480 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:47.39 [ET_AIO 3]
> 32488 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.16 [ET_AIO 3]
> 32489 ats 20 0 59.3g 45g 25m S 12.8 72.1 16:50.79 [ET_AIO 4]
> 32490 ats 20 0 59.3g 45g 25m R 12.8 72.1 16:52.61 [ET_AIO 5]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2206) traffic_line in the RC/trafficserver script does not use absolute path
Leif Hedstrom created TS-2206: - Summary: traffic_line in the RC/trafficserver script does not use absolute path Key: TS-2206 URL: https://issues.apache.org/jira/browse/TS-2206 Project: Traffic Server Issue Type: Bug Components: Management Reporter: Leif Hedstrom This causes installations where traffic_line is not in the normal search path to not be able to do e.g. trafficserver reload. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2206) traffic_line in the RC/trafficserver script does not use absolute path
[ https://issues.apache.org/jira/browse/TS-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2206: -- Fix Version/s: 4.1.0 Assignee: Leif Hedstrom > traffic_line in the RC/trafficserver script does not use absolute path > -- > > Key: TS-2206 > URL: https://issues.apache.org/jira/browse/TS-2206 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 4.1.0 > > > This causes installations where traffic_line is not in the normal search path > to not be able to do e.g. trafficserver reload. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
[ https://issues.apache.org/jira/browse/TS-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommy Lee updated TS-2193: -- Attachment: bt-01.txt GDB Backtrace > 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.0 >Reporter: Tommy Lee > Fix For: 4.1.0 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
[ https://issues.apache.org/jira/browse/TS-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763084#comment-13763084 ] Tommy Lee commented on TS-2193: --- Leif and John, I'm running without plugins right now, but i use cacheurl plugin in production environment. I'm attaching the first BT from gdb. The steps that I use to reproduce are: Set ATS is forward proxy mode, configure dns.dedicated = 1 and configure my browser to use this proxy. There's one thing that intrigues me. If i visit www.speedtest.net, and click in button "Begin Test", the crash occurs instantly. If i use other websites, the crash doesn't shows up frequently. Thanks in advance. > 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.0 >Reporter: Tommy Lee > Fix For: 4.1.0 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2185) support to control ClusterCom::sendSharedData frequency
[ https://issues.apache.org/jira/browse/TS-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763104#comment-13763104 ] ASF subversion and git services commented on TS-2185: - Commit 0a92bcdccec4e79e1527521a01f2a464a7d6ce28 in branch refs/heads/5.0.x from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0a92bcd ] TS-2185: support to control ClusterCom::sendSharedData frequency > support to control ClusterCom::sendSharedData frequency > --- > > Key: TS-2185 > URL: https://issues.apache.org/jira/browse/TS-2185 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.1.0 > > Attachments: TS-2185.patch > > > support to control ClusterCom::sendSharedData frequency. The original design > ClusterCom::sendSharedData will be called every loop. It's so frequent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1637) nodes as idle/dead if we have not heard from them in awhile
[ https://issues.apache.org/jira/browse/TS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763103#comment-13763103 ] ASF subversion and git services commented on TS-1637: - Commit cb9b0ffd8e9b4fb0f1b6909918abb2894eb76217 in branch refs/heads/5.0.x from [~kuotai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cb9b0ff ] TS-1637: Fix nodes as idle/dead if we have not heard from them in awhile > nodes as idle/dead if we have not heard from them in awhile > --- > > Key: TS-1637 > URL: https://issues.apache.org/jira/browse/TS-1637 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Management >Affects Versions: 3.2.0 >Reporter: Bin Chen >Assignee: Bin Chen > Fix For: 4.1.0 > > Attachments: TS-1637.patch, TS-1637_v2.patch > > > in ClusterCom::sendReliableMessageReadTillClose(), if we can't connect peer > node quickly(if timeout, will > 30s(default peer_timeout)), then won't send > Shared date called by ClusterCom::sendSharedData. So peer node will marking > me down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2207) Centos5 out of tree perl build fails
[
https://issues.apache.org/jira/browse/TS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763154#comment-13763154
]
ASF subversion and git services commented on TS-2207:
-
Commit 632b3a40241fc4459fc8126d5a0961ba08151021 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=632b3a4 ]
TS-2207: CentOS5 out of tree perl module build fails
The older version of automake on CentOS5 doesn't supply the $(builddir)
variable, possibly because it's implicitly the current working
directory. It also doesn't supply various $abs_ variables that later
versions do. Rewrite the copy using more fundamental automake
variables.
> Centos5 out of tree perl build fails
>
>
> Key: TS-2207
> URL: https://issues.apache.org/jira/browse/TS-2207
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: James Peach
>
> On Centos5, the perl module build fails when {{$(srcdir)}} != {{$(builder)}}.
> For example,
> https://ci.trafficserver.apache.org/job/centos_5_x64-master-debug-regression/lastFailedBuild/console:
> {code}
> make[2]: Entering directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
> [ /var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl != ]
> && cp -rf /. /.
> /bin/sh: line 0: [:
> /var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl: unary
> operator expected
> make[2]: [Makefile-pl] Error 2 (ignored)
> /usr/bin/perl Makefile.PL INSTALLDIRS=
> PREFIX=/var/jenkins/workspace/centos_5_x64-master-debug-regression/install/centos_5_x64-master-debug-regression.50
> Can't open perl script "Makefile.PL": No such file or directory
> make[2]: *** [Makefile-pl] Error 2
> make[2]: Leaving directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib'
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2206) traffic_line in the RC/trafficserver script does not use absolute path
[ https://issues.apache.org/jira/browse/TS-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763155#comment-13763155 ] ASF subversion and git services commented on TS-2206: - Commit a6067e19b3f2fe8daa5f8f9509ec11f243c4c60c in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a6067e1 ] TS-2206 The trafficserver RC script does not use absolute path to traffic_line binary. > traffic_line in the RC/trafficserver script does not use absolute path > -- > > Key: TS-2206 > URL: https://issues.apache.org/jira/browse/TS-2206 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 4.1.0 > > > This causes installations where traffic_line is not in the normal search path > to not be able to do e.g. trafficserver reload. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2207) Centos5 out of tree perl build fails
[
https://issues.apache.org/jira/browse/TS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763170#comment-13763170
]
ASF subversion and git services commented on TS-2207:
-
Commit 00b8856578ec733ae7dea76ade43efe44b6a8e69 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=00b8856 ]
TS-2207: stop using $(builddir) in automake
Older automake (< 1.9?) doesn't emit $(builddir), but it's always
"." anyway, so let's use that instead.
> Centos5 out of tree perl build fails
>
>
> Key: TS-2207
> URL: https://issues.apache.org/jira/browse/TS-2207
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: James Peach
>
> On Centos5, the perl module build fails when {{$(srcdir)}} != {{$(builder)}}.
> For example,
> https://ci.trafficserver.apache.org/job/centos_5_x64-master-debug-regression/lastFailedBuild/console:
> {code}
> make[2]: Entering directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
> [ /var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl != ]
> && cp -rf /. /.
> /bin/sh: line 0: [:
> /var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl: unary
> operator expected
> make[2]: [Makefile-pl] Error 2 (ignored)
> /usr/bin/perl Makefile.PL INSTALLDIRS=
> PREFIX=/var/jenkins/workspace/centos_5_x64-master-debug-regression/install/centos_5_x64-master-debug-regression.50
> Can't open perl script "Makefile.PL": No such file or directory
> make[2]: *** [Makefile-pl] Error 2
> make[2]: Leaving directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib'
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2207) Centos5 out of tree perl build fails
James Peach created TS-2207:
---
Summary: Centos5 out of tree perl build fails
Key: TS-2207
URL: https://issues.apache.org/jira/browse/TS-2207
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: James Peach
On Centos5, the perl module build fails when {{$(srcdir)}} != {{$(builder)}}.
For example,
https://ci.trafficserver.apache.org/job/centos_5_x64-master-debug-regression/lastFailedBuild/console:
{code}
make[2]: Entering directory
`/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
[ /var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl != ] &&
cp -rf /. /.
/bin/sh: line 0: [:
/var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl: unary
operator expected
make[2]: [Makefile-pl] Error 2 (ignored)
/usr/bin/perl Makefile.PL INSTALLDIRS=
PREFIX=/var/jenkins/workspace/centos_5_x64-master-debug-regression/install/centos_5_x64-master-debug-regression.50
Can't open perl script "Makefile.PL": No such file or directory
make[2]: *** [Makefile-pl] Error 2
make[2]: Leaving directory
`/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib'
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2207) Centos5 out of tree perl build fails
[
https://issues.apache.org/jira/browse/TS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2207.
-
Resolution: Fixed
Fix Version/s: 4.1.0
Assignee: James Peach
> Centos5 out of tree perl build fails
>
>
> Key: TS-2207
> URL: https://issues.apache.org/jira/browse/TS-2207
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.1.0
>
>
> On Centos5, the perl module build fails when {{$(srcdir)}} != {{$(builder)}}.
> For example,
> https://ci.trafficserver.apache.org/job/centos_5_x64-master-debug-regression/lastFailedBuild/console:
> {code}
> make[2]: Entering directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
> [ /var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl != ]
> && cp -rf /. /.
> /bin/sh: line 0: [:
> /var/jenkins/workspace/centos_5_x64-master-debug-regression/lib/perl: unary
> operator expected
> make[2]: [Makefile-pl] Error 2 (ignored)
> /usr/bin/perl Makefile.PL INSTALLDIRS=
> PREFIX=/var/jenkins/workspace/centos_5_x64-master-debug-regression/install/centos_5_x64-master-debug-regression.50
> Can't open perl script "Makefile.PL": No such file or directory
> make[2]: *** [Makefile-pl] Error 2
> make[2]: Leaving directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib/perl'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/var/jenkins/workspace/centos_5_x64-master-debug-regression/build/centos_5_x64-master-debug-regression.50/lib'
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
[ https://issues.apache.org/jira/browse/TS-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763219#comment-13763219 ] John Plevyak commented on TS-2193: -- I am concerned about the proxy.config.dns.dedicated_thread option. It is testing a configuration where event threads are not ET_NET. While originally the design accounted for that possibility, it was the case that all event threads were ET_NET soon thereafter and I an worried that there are implicit assumptions that it is the case (as seems to be with the session manager). Is this really necessary? DNS processing should be cheap. Several fixes come to mind: 1) make the SessionManager not depend on being called on an ET_NET (this should probably be done in any case). It could simply shift to any ET_NET thread if it was called from another. 2) make the DNS processor call back on an ET_NET thread (this is stupid since there is no good reason for it to assume the caller has such a restriction and indeed what about the other ET_ type?). 3) make the DNS processor run across threads by hashing hosts to all ET_NET threads. This will fix both the issue we are seeing as well as spread the load. We should probably do both 1 and 3. There will be a temptation to do 2) because it will be the "easy" fix but I think it is the wrong way out. > 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.0 >Reporter: Tommy Lee > Fix For: 4.1.0 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2193) Trafficserver 4.1 Crash with proxy.config.dns.dedicated_thread = 1
[ https://issues.apache.org/jira/browse/TS-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763225#comment-13763225 ] John Plevyak commented on TS-2193: -- This is listed as an experimental performance feature. Personally, I would like to see some numbers before committing resources otherwise I would say that the experiment was a failure. > 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.0 >Reporter: Tommy Lee > Fix For: 4.1.0 > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2198) backport: CLONE - when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
[ https://issues.apache.org/jira/browse/TS-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763177#comment-13763177 ] Leif Hedstrom commented on TS-2198: --- Should this really be back ported to v4.0.2 ? There's not even a commit on this yet? > backport: CLONE - when http_info enabled, the http_sm may be deleted but a > event associated it not cancelled. > -- > > Key: TS-2198 > URL: https://issues.apache.org/jira/browse/TS-2198 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 4.0.2 > > Attachments: TS-2191.wj.diff > > > if the http_info enabled, when the sm_list`s lock not acquired but the > client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2198) backport: CLONE - when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
[ https://issues.apache.org/jira/browse/TS-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2198: -- Backport to Version: (was: 4.0.2) Fix Version/s: (was: 4.0.2) Ah, I think I see what happened, there's no need to clone "back port" bugs any more, just mark the bug you committed on master to also be a back port to 4.0.2 (in this case) and the current RM will investigate. > backport: CLONE - when http_info enabled, the http_sm may be deleted but a > event associated it not cancelled. > -- > > Key: TS-2198 > URL: https://issues.apache.org/jira/browse/TS-2198 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Zhao Yongming >Assignee: weijin > Attachments: TS-2191.wj.diff > > > if the http_info enabled, when the sm_list`s lock not acquired but the > client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-2198) backport: CLONE - when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
[ https://issues.apache.org/jira/browse/TS-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom closed TS-2198. - Resolution: Invalid > backport: CLONE - when http_info enabled, the http_sm may be deleted but a > event associated it not cancelled. > -- > > Key: TS-2198 > URL: https://issues.apache.org/jira/browse/TS-2198 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Zhao Yongming >Assignee: weijin > Attachments: TS-2191.wj.diff > > > if the http_info enabled, when the sm_list`s lock not acquired but the > client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2200) the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin use these macros
[ https://issues.apache.org/jira/browse/TS-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763182#comment-13763182 ] Leif Hedstrom commented on TS-2200: --- Maybe it's time to move these to ts/ts.h ? > the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin > use these macros > -- > > Key: TS-2200 > URL: https://issues.apache.org/jira/browse/TS-2200 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Yu Qing >Assignee: Yu Qing > Attachments: 0001-define-macro-TS_HRTIME_XXX-directly.patch > > > such macro defines in proxy/api/ts/experimental.h: > #define TS_HRTIME_FOREVER HRTIME_FOREVER > #define TS_HRTIME_DECADE HRTIME_DECADE > #define TS_HRTIME_YEAR HRTIME_YEAR > #define TS_HRTIME_WEEK HRTIME_WEEK > #define TS_HRTIME_DAY HRTIME_DAY > #define TS_HRTIME_HOUR HRTIME_HOUR > #define TS_HRTIME_MINUTE HRTIME_MINUTE > #define TS_HRTIME_SECOND HRTIME_SECOND > #define TS_HRTIME_MSECOND HRTIME_MSECOND > #define TS_HRTIME_USECOND HRTIME_USECOND > #define TS_HRTIME_NSECOND HRTIME_NSECOND > ... > The macros of HRTIME_xxx (such as HRTIME_SECOND) in lib/ts/ink_hrtime.h。 > Because the TS plugins SHOULD not include the header file ink_hrtime.h, so > they can't use above macros like TS_HRTIME_xxx。 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2191) when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
[ https://issues.apache.org/jira/browse/TS-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2191. --- Resolution: Fixed > when http_info enabled, the http_sm may be deleted but a event associated it > not cancelled. > > > Key: TS-2191 > URL: https://issues.apache.org/jira/browse/TS-2191 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: weijin > Fix For: 4.1.0 > > Attachments: TS-2191.wj.diff > > > if the http_info enabled, when the sm_list`s lock not acquired but the > client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2173) cache total hit/miss stats broken in version 4.0.1
[ https://issues.apache.org/jira/browse/TS-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2173: -- Backport to Version: (was: 4.0.2) > cache total hit/miss stats broken in version 4.0.1 > -- > > Key: TS-2173 > URL: https://issues.apache.org/jira/browse/TS-2173 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Affects Versions: 4.0.1 >Reporter: Scott Harris >Assignee: Yunkai Zhang > Fix For: 4.0.2, 4.1.0 > > Attachments: > 0001-TS-2173-RECD_COUNTER-type-is-missing-in-setTokenValu.patch > > > In version 4.0.1 both proxy.node.cache_total_hits and > proxy.node.cache_total_misses always return 0 > In version 3.2.5 both stats returned correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2173) cache total hit/miss stats broken in version 4.0.1
[ https://issues.apache.org/jira/browse/TS-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2173: -- Fix Version/s: 4.0.2 > cache total hit/miss stats broken in version 4.0.1 > -- > > Key: TS-2173 > URL: https://issues.apache.org/jira/browse/TS-2173 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Affects Versions: 4.0.1 >Reporter: Scott Harris >Assignee: Yunkai Zhang > Fix For: 4.0.2, 4.1.0 > > Attachments: > 0001-TS-2173-RECD_COUNTER-type-is-missing-in-setTokenValu.patch > > > In version 4.0.1 both proxy.node.cache_total_hits and > proxy.node.cache_total_misses always return 0 > In version 3.2.5 both stats returned correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2191) when http_info enabled, the http_sm may be deleted but a event associated it not cancelled.
[ https://issues.apache.org/jira/browse/TS-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2191: -- Fix Version/s: 4.1.0 > when http_info enabled, the http_sm may be deleted but a event associated it > not cancelled. > > > Key: TS-2191 > URL: https://issues.apache.org/jira/browse/TS-2191 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: weijin > Fix For: 4.1.0 > > Attachments: TS-2191.wj.diff > > > if the http_info enabled, when the sm_list`s lock not acquired but the > client_vc`s timeout event triggered, the race may lead ts crash. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763186#comment-13763186
]
Leif Hedstrom commented on TS-2174:
---
Backported to 4.0.2
> traffic_shell/traffic_line miss some stats value
>
>
> Key: TS-2174
> URL: https://issues.apache.org/jira/browse/TS-2174
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.1.0
>
> Attachments:
> 0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
> 0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
>
>
> I'm sorry for too late to fix this bug.
> Here is an example about the broken of traffic_shell(reported by
> Esmq ):
> {code}
> echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
> Successfully Initialized MgmtAPI in
> /usr/local/trafficserver-4.0.1/var/trafficserver
> trafficserver>
> Document Hit Rate 0.00 %*
> Ram cache Hit Rate --- 0.00 %*
> Bandwidth Saving - 0.00 %*
> Cache Percent Free --- 0.00 %
> Open Server Connections -- 473
> Open Client Connections -- 3796
> Open Cache Connections --- 1
> Client Throughput 18.100512 MBit/Sec
> Transaction Per Second --- 0.00
> {code}
> The root cause is that StatBinaryEval() use RecInt type to hold the result of
> *div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2200) the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin use these macros
[ https://issues.apache.org/jira/browse/TS-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2200: -- Fix Version/s: 4.1.0 > the macro TS_HRTIME_xxx in proxy/api/ts/experimental.h is invalid when plugin > use these macros > -- > > Key: TS-2200 > URL: https://issues.apache.org/jira/browse/TS-2200 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.1.0 > > Attachments: 0001-define-macro-TS_HRTIME_XXX-directly.patch > > > such macro defines in proxy/api/ts/experimental.h: > #define TS_HRTIME_FOREVER HRTIME_FOREVER > #define TS_HRTIME_DECADE HRTIME_DECADE > #define TS_HRTIME_YEAR HRTIME_YEAR > #define TS_HRTIME_WEEK HRTIME_WEEK > #define TS_HRTIME_DAY HRTIME_DAY > #define TS_HRTIME_HOUR HRTIME_HOUR > #define TS_HRTIME_MINUTE HRTIME_MINUTE > #define TS_HRTIME_SECOND HRTIME_SECOND > #define TS_HRTIME_MSECOND HRTIME_MSECOND > #define TS_HRTIME_USECOND HRTIME_USECOND > #define TS_HRTIME_NSECOND HRTIME_NSECOND > ... > The macros of HRTIME_xxx (such as HRTIME_SECOND) in lib/ts/ink_hrtime.h。 > Because the TS plugins SHOULD not include the header file ink_hrtime.h, so > they can't use above macros like TS_HRTIME_xxx。 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-2206) traffic_line in the RC/trafficserver script does not use absolute path
[ https://issues.apache.org/jira/browse/TS-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2206. --- Resolution: Fixed > traffic_line in the RC/trafficserver script does not use absolute path > -- > > Key: TS-2206 > URL: https://issues.apache.org/jira/browse/TS-2206 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 4.1.0 > > > This causes installations where traffic_line is not in the normal search path > to not be able to do e.g. trafficserver reload. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2208) LogFilter does not have a way to configure "conjunction"
Leif Hedstrom created TS-2208:
-
Summary: LogFilter does not have a way to configure "conjunction"
Key: TS-2208
URL: https://issues.apache.org/jira/browse/TS-2208
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Leif Hedstrom
In the LogFilter implementation details, there's code to deal with "OR" and
"AND" such that you can express either
REJECT if x AND y
or
REJECT if x OR y
However, there's no way to configure this in logs_xml.config,
m_does_conjunction is always true afaik (so only the OR case above is
supported). So even though the code supports both of the above, there's no way
to express it:
{code}
bool m_does_conjunction;
// If m_does_conjunction = true
// toss_this_entry returns true
// if ANY filter tosses entry away.
// If m_does_conjunction = false,
// toss this entry returns true if
// ALL filters toss away entry
{code}
This seems properly implemented in the LogFilterList::toss_this_entry() method:
{code}
bool LogFilterList::toss_this_entry(LogAccess * lad)
{
if (m_does_conjunction) {
// toss if any filter rejects the entry (all filters should accept)
//
for (LogFilter * f = first(); f; f = next(f)) {
if (f->toss_this_entry(lad)) {
return true;
}
}
return false;
} else {
// toss if all filters reject the entry (any filter accepts)
//
for (LogFilter * f = first(); f; f = next(f)) {
if (!f->toss_this_entry(lad)) {
return false;
}
}
return true;
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2208) LogFilter does not have a way to configure "conjunction"
[
https://issues.apache.org/jira/browse/TS-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2208:
--
Fix Version/s: 4.1.0
> LogFilter does not have a way to configure "conjunction"
>
>
> Key: TS-2208
> URL: https://issues.apache.org/jira/browse/TS-2208
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Leif Hedstrom
> Fix For: 4.1.0
>
>
> In the LogFilter implementation details, there's code to deal with "OR" and
> "AND" such that you can express either
> REJECT if x AND y
> or
> REJECT if x OR y
> However, there's no way to configure this in logs_xml.config,
> m_does_conjunction is always true afaik (so only the OR case above is
> supported). So even though the code supports both of the above, there's no
> way to express it:
> {code}
> bool m_does_conjunction;
> // If m_does_conjunction = true
> // toss_this_entry returns true
> // if ANY filter tosses entry away.
> // If m_does_conjunction = false,
> // toss this entry returns true if
> // ALL filters toss away entry
> {code}
> This seems properly implemented in the LogFilterList::toss_this_entry()
> method:
> {code}
> bool LogFilterList::toss_this_entry(LogAccess * lad)
> {
> if (m_does_conjunction) {
> // toss if any filter rejects the entry (all filters should accept)
> //
> for (LogFilter * f = first(); f; f = next(f)) {
> if (f->toss_this_entry(lad)) {
> return true;
> }
> }
> return false;
> } else {
> // toss if all filters reject the entry (any filter accepts)
> //
> for (LogFilter * f = first(); f; f = next(f)) {
> if (!f->toss_this_entry(lad)) {
> return false;
> }
> }
> return true;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2174:
--
Backport to Version: (was: 4.0.2)
> traffic_shell/traffic_line miss some stats value
>
>
> Key: TS-2174
> URL: https://issues.apache.org/jira/browse/TS-2174
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.0.2, 4.1.0
>
> Attachments:
> 0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
> 0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
>
>
> I'm sorry for too late to fix this bug.
> Here is an example about the broken of traffic_shell(reported by
> Esmq ):
> {code}
> echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
> Successfully Initialized MgmtAPI in
> /usr/local/trafficserver-4.0.1/var/trafficserver
> trafficserver>
> Document Hit Rate 0.00 %*
> Ram cache Hit Rate --- 0.00 %*
> Bandwidth Saving - 0.00 %*
> Cache Percent Free --- 0.00 %
> Open Server Connections -- 473
> Open Client Connections -- 3796
> Open Cache Connections --- 1
> Client Throughput 18.100512 MBit/Sec
> Transaction Per Second --- 0.00
> {code}
> The root cause is that StatBinaryEval() use RecInt type to hold the result of
> *div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2174:
--
Fix Version/s: 4.0.2
> traffic_shell/traffic_line miss some stats value
>
>
> Key: TS-2174
> URL: https://issues.apache.org/jira/browse/TS-2174
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.0.2, 4.1.0
>
> Attachments:
> 0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
> 0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
>
>
> I'm sorry for too late to fix this bug.
> Here is an example about the broken of traffic_shell(reported by
> Esmq ):
> {code}
> echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
> Successfully Initialized MgmtAPI in
> /usr/local/trafficserver-4.0.1/var/trafficserver
> trafficserver>
> Document Hit Rate 0.00 %*
> Ram cache Hit Rate --- 0.00 %*
> Bandwidth Saving - 0.00 %*
> Cache Percent Free --- 0.00 %
> Open Server Connections -- 473
> Open Client Connections -- 3796
> Open Cache Connections --- 1
> Client Throughput 18.100512 MBit/Sec
> Transaction Per Second --- 0.00
> {code}
> The root cause is that StatBinaryEval() use RecInt type to hold the result of
> *div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1740) Improve precision of stats's values
[
https://issues.apache.org/jira/browse/TS-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763196#comment-13763196
]
ASF subversion and git services commented on TS-1740:
-
Commit e543f69596fd73e60736d43709a581e29e3273b5 in branch refs/heads/4.0.x from
[~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e543f69 ]
TS-2173: RECD_COUNTER type is missing in setTokenValue()
After applied "TS-1740: Improve precision of stats values" patch,
each token will keep its original type instead of forcing to RecFloat.
So we should update setTokenValue() to deal with RECD_COUNTER case.
Signed-off-by: Yunkai Zhang
Conflicts:
CHANGES
> Improve precision of stats's values
> ---
>
> Key: TS-1740
> URL: https://issues.apache.org/jira/browse/TS-1740
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>Assignee: Zhao Yongming
> Fix For: 3.3.2
>
> Attachments: 0001-Improve-precision-of-stats-s-values.patch
>
>
> Improve precision of stats's values
> Conversion between types, such as RecInt(int64_t) to RecFloat(float),
> may lead to loss of precision.
> In the old code, token value was defined with StatFloat type, it would casue
> unnecessary conversion when type of token is not StatFloat.
> it's best to keep value with the same type of token as much as possiable.
> ===
> For example, we have defined such expression in stats.config.xml:
> {code}
>
>
> proxy.node.http.user_agent_total_request_bytes
> scope="cluster">proxy.cluster.http.user_agent_total_request_bytes
>
> proxy.process.http.user_agent_request_document_total_size +
> proxy.process.http.user_agent_request_header_total_size
>
>
> {code}
> So:
> proxy.node.http.user_agent_total_request_bytes = \
> proxy.process.http.user_agent_request_document_total_size + \
> proxy.process.http.user_agent_request_header_total_size
> These three stats token are all RecInt types, but the code would convert them
> to RecFloat when evaluating the expression, like that:
> proxy.node.http.user_agent_total_request_bytes = \
> (RecFloat)proxy.process.http.user_agent_request_document_total_size + \
> (RecFloat)proxy.process.http.user_agent_request_header_total_size
> As a result, we might get the following output from stats http API:
> {code}
> [root@test62 trafficserver]# cat ~/bin/list-cluster.sh
> elinks -dump http://localhost:8080/stat/ | grep proxy_name
> elinks -dump http://localhost:8080/stat/ | grep nodes
> elinks -dump http://localhost:8080/stat/ | grep
> proxy.process.http.origin_server_request_document_total_size
> elinks -dump http://localhost:8080/stat/ | grep
> proxy.process.http.origin_server_request_header_total_size
> elinks -dump http://localhost:8080/stat/ | grep
> proxy.node.http.origin_server_total_request_bytes
> [root@test62 trafficserver]# list-cluster.sh
> proxy.config.proxy_name=test62.63
> proxy.node.cluster.nodes=1
> proxy.process.cluster.nodes=1
> proxy.process.http.origin_server_request_document_total_size=0<= #1
> proxy.process.http.origin_server_request_header_total_size=359209123 <= #2
> proxy.node.http.origin_server_total_request_bytes=359209120 <= #3
> != (#1 + #2)
> {code}
> As the value increasing, the loss of precision will become more and more
> seriously.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763194#comment-13763194
]
ASF subversion and git services commented on TS-2174:
-
Commit 3751008cb64a9b37227ff40659895dd322ac322a in branch refs/heads/4.0.x from
[~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3751008 ]
TS-2174: Fix StatBinaryEval() on div operation
We should fore the type of result to be RecFloat on div operation,
otherwise we can't get the fraction when dividing two RecInt.
Signed-off-by: Yunkai Zhang
> traffic_shell/traffic_line miss some stats value
>
>
> Key: TS-2174
> URL: https://issues.apache.org/jira/browse/TS-2174
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.0.2, 4.1.0
>
> Attachments:
> 0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
> 0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
>
>
> I'm sorry for too late to fix this bug.
> Here is an example about the broken of traffic_shell(reported by
> Esmq ):
> {code}
> echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
> Successfully Initialized MgmtAPI in
> /usr/local/trafficserver-4.0.1/var/trafficserver
> trafficserver>
> Document Hit Rate 0.00 %*
> Ram cache Hit Rate --- 0.00 %*
> Bandwidth Saving - 0.00 %*
> Cache Percent Free --- 0.00 %
> Open Server Connections -- 473
> Open Client Connections -- 3796
> Open Cache Connections --- 1
> Client Throughput 18.100512 MBit/Sec
> Transaction Per Second --- 0.00
> {code}
> The root cause is that StatBinaryEval() use RecInt type to hold the result of
> *div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2174) traffic_shell/traffic_line miss some stats value
[
https://issues.apache.org/jira/browse/TS-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763193#comment-13763193
]
ASF subversion and git services commented on TS-2174:
-
Commit e41e03e599bda2c5528ef6617de2fec34cb8a848 in branch refs/heads/4.0.x from
[~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e41e03e ]
TS-2174: Assign proper type for uninitialized expression token
In librecords, not all token are register at initialization,
we must assign proper type if it is undefined.
Signed-off-by: Yunkai Zhang
Conflicts:
CHANGES
> traffic_shell/traffic_line miss some stats value
>
>
> Key: TS-2174
> URL: https://issues.apache.org/jira/browse/TS-2174
> Project: Traffic Server
> Issue Type: Bug
> Components: Stats
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.0.2, 4.1.0
>
> Attachments:
> 0001-TS-2174-Assign-proper-type-for-uninitialized-express.patch,
> 0001-TS-2174-Fix-StatBinaryEval-on-div-operation.patch
>
>
> I'm sorry for too late to fix this bug.
> Here is an example about the broken of traffic_shell(reported by
> Esmq ):
> {code}
> echo 'show:proxy-stats' | sudo /usr/local/trafficserver/bin/traffic_shell
> Successfully Initialized MgmtAPI in
> /usr/local/trafficserver-4.0.1/var/trafficserver
> trafficserver>
> Document Hit Rate 0.00 %*
> Ram cache Hit Rate --- 0.00 %*
> Bandwidth Saving - 0.00 %*
> Cache Percent Free --- 0.00 %
> Open Server Connections -- 473
> Open Client Connections -- 3796
> Open Cache Connections --- 1
> Client Throughput 18.100512 MBit/Sec
> Transaction Per Second --- 0.00
> {code}
> The root cause is that StatBinaryEval() use RecInt type to hold the result of
> *div* operation when operands are RecInt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2173) cache total hit/miss stats broken in version 4.0.1
[ https://issues.apache.org/jira/browse/TS-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763195#comment-13763195 ] ASF subversion and git services commented on TS-2173: - Commit e543f69596fd73e60736d43709a581e29e3273b5 in branch refs/heads/4.0.x from [~yunkai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=e543f69 ] TS-2173: RECD_COUNTER type is missing in setTokenValue() After applied "TS-1740: Improve precision of stats values" patch, each token will keep its original type instead of forcing to RecFloat. So we should update setTokenValue() to deal with RECD_COUNTER case. Signed-off-by: Yunkai Zhang Conflicts: CHANGES > cache total hit/miss stats broken in version 4.0.1 > -- > > Key: TS-2173 > URL: https://issues.apache.org/jira/browse/TS-2173 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Affects Versions: 4.0.1 >Reporter: Scott Harris >Assignee: Yunkai Zhang > Fix For: 4.0.2, 4.1.0 > > Attachments: > 0001-TS-2173-RECD_COUNTER-type-is-missing-in-setTokenValu.patch > > > In version 4.0.1 both proxy.node.cache_total_hits and > proxy.node.cache_total_misses always return 0 > In version 3.2.5 both stats returned correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-2173) cache total hit/miss stats broken in version 4.0.1
[ https://issues.apache.org/jira/browse/TS-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763184#comment-13763184 ] Leif Hedstrom commented on TS-2173: --- Backporting to 4.0.2. > cache total hit/miss stats broken in version 4.0.1 > -- > > Key: TS-2173 > URL: https://issues.apache.org/jira/browse/TS-2173 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Affects Versions: 4.0.1 >Reporter: Scott Harris >Assignee: Yunkai Zhang > Fix For: 4.1.0 > > Attachments: > 0001-TS-2173-RECD_COUNTER-type-is-missing-in-setTokenValu.patch > > > In version 4.0.1 both proxy.node.cache_total_hits and > proxy.node.cache_total_misses always return 0 > In version 3.2.5 both stats returned correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-2209) add support for lowercasing all substitutions in regex_remap
Bryan Call created TS-2209: -- Summary: add support for lowercasing all substitutions in regex_remap Key: TS-2209 URL: https://issues.apache.org/jira/browse/TS-2209 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Bryan Call Add the option @lowercase_substitutions=1 to regex_remap to lowercase all the matching substitutions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-2209) add support for lowercasing all substitutions in regex_remap
[ https://issues.apache.org/jira/browse/TS-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call reassigned TS-2209: -- Assignee: Bryan Call > add support for lowercasing all substitutions in regex_remap > > > Key: TS-2209 > URL: https://issues.apache.org/jira/browse/TS-2209 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Bryan Call >Assignee: Bryan Call > > Add the option @lowercase_substitutions=1 to regex_remap to lowercase all the > matching substitutions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2209) add support for lowercasing all substitutions in regex_remap
[ https://issues.apache.org/jira/browse/TS-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2209: --- Fix Version/s: 4.1.0 > add support for lowercasing all substitutions in regex_remap > > > Key: TS-2209 > URL: https://issues.apache.org/jira/browse/TS-2209 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 4.1.0 > > > Add the option @lowercase_substitutions=1 to regex_remap to lowercase all the > matching substitutions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-2209) add support for lowercasing all substitutions in regex_remap
[ https://issues.apache.org/jira/browse/TS-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-2209: --- Attachment: ts-2209.diff > add support for lowercasing all substitutions in regex_remap > > > Key: TS-2209 > URL: https://issues.apache.org/jira/browse/TS-2209 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 4.1.0 > > Attachments: ts-2209.diff > > > Add the option @lowercase_substitutions=1 to regex_remap to lowercase all the > matching substitutions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
