[jira] [Commented] (TS-2431) Add SPDY supporting to ATS
[ https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854814#comment-13854814 ] Yunkai Zhang commented on TS-2431: -- That is OK, I must say sorry, I had no time to finished it last week, too busy at Taobao. > Add SPDY supporting to ATS > -- > > Key: TS-2431 > URL: https://issues.apache.org/jira/browse/TS-2431 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Yunkai Zhang > > I'm working on it. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (TS-2435) Broken links on download page
[ https://issues.apache.org/jira/browse/TS-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb closed TS-2435. Thanks > Broken links on download page > - > > Key: TS-2435 > URL: https://issues.apache.org/jira/browse/TS-2435 > Project: Traffic Server > Issue Type: Bug >Reporter: Sebb >Assignee: Miles Libbey > Fix For: Docs > > > http://trafficserver.apache.org/downloads > has sig and hash links for older releases: > Archived (stable) Release -- 4.0.1 > Archived (stable) Release -- 3.2.4 > Archived (stable) Release -- 3.2.0 > This is good, but the links need to point to the archive server. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (TS-2448) traffic_cop and traffic_manager ignore proxy.config.local_state_dir
[
https://issues.apache.org/jira/browse/TS-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2448.
-
Resolution: Fixed
> traffic_cop and traffic_manager ignore proxy.config.local_state_dir
> ---
>
> Key: TS-2448
> URL: https://issues.apache.org/jira/browse/TS-2448
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, cop, Management
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
>
> {{traffic_cop}} and {{traffic_manager}} ignore the
> {{proxy.config.local_state_dir}} configuration variable.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (TS-2448) traffic_cop and traffic_manager ignore proxy.config.local_state_dir
[
https://issues.apache.org/jira/browse/TS-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854674#comment-13854674
]
ASF subversion and git services commented on TS-2448:
-
Commit aae02ee4fd133ec604b3e7bd7d090cd05f29750e in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=aae02ee ]
TS-2448: Fix traffic_manager to work correctly if proxy.config.local_state_dir
is set
> traffic_cop and traffic_manager ignore proxy.config.local_state_dir
> ---
>
> Key: TS-2448
> URL: https://issues.apache.org/jira/browse/TS-2448
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, cop, Management
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
>
> {{traffic_cop}} and {{traffic_manager}} ignore the
> {{proxy.config.local_state_dir}} configuration variable.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (TS-2448) traffic_cop and traffic_manager ignore proxy.config.local_state_dir
[
https://issues.apache.org/jira/browse/TS-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854673#comment-13854673
]
ASF subversion and git services commented on TS-2448:
-
Commit b78aa56acccb74b3a507fd8642fdb847b34f76bf in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b78aa56 ]
TS-2448: Fix traffic_cop to work correctly if proxy.config.local_state_dir is
set
> traffic_cop and traffic_manager ignore proxy.config.local_state_dir
> ---
>
> Key: TS-2448
> URL: https://issues.apache.org/jira/browse/TS-2448
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, cop, Management
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
>
> {{traffic_cop}} and {{traffic_manager}} ignore the
> {{proxy.config.local_state_dir}} configuration variable.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (TS-2248) Segmentation fault HttpTunnel
[ https://issues.apache.org/jira/browse/TS-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854675#comment-13854675 ] ASF subversion and git services commented on TS-2248: - Commit 3421c6e42e04cffdfd9bea5a23f73ec9a8743c7c in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3421c6e ] TS-2248: update CHANGES > Segmentation fault HttpTunnel > -- > > Key: TS-2248 > URL: https://issues.apache.org/jira/browse/TS-2248 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.0.1 >Reporter: bettydramit > Labels: Crash > Fix For: sometime > > > ENV: centos 6 x86_64 ts-4.0.1 > NOTE: Traffic Server received Sig 11: Segmentation fault > /usr/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0(+0xf500)[0x2b934f388500] > /usr/bin/traffic_server(HttpTunnel::consumer_reenable(HttpTunnelConsumer*)+0x13a)[0x56aa2a] > /usr/bin/traffic_server(HttpTunnel::consumer_handler(int, > HttpTunnelConsumer*)+0x16b)[0x56aceb] > /usr/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0x10d)[0x56bc2d] > /usr/bin/traffic_server[0x6807bb] > /usr/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*, > EThread*)+0x553)[0x6841a3] > /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x283)[0x67bd93] > /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a36df] > /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a40c3] > /usr/bin/traffic_server[0x6a257a] > /lib64/libpthread.so.0(+0x7851)[0x2b934f380851] > /lib64/libc.so.6(clone+0x6d)[0x2b935002494d] -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2448) traffic_cop and traffic_manager ignore proxy.config.local_state_dir
[
https://issues.apache.org/jira/browse/TS-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2448:
Fix Version/s: 4.2.0
Assignee: James Peach
> traffic_cop and traffic_manager ignore proxy.config.local_state_dir
> ---
>
> Key: TS-2448
> URL: https://issues.apache.org/jira/browse/TS-2448
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, cop, Management
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
>
> {{traffic_cop}} and {{traffic_manager}} ignore the
> {{proxy.config.local_state_dir}} configuration variable.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (TS-2448) traffic_cop and traffic_manager ignore proxy.config.local_state_dir
James Peach created TS-2448:
---
Summary: traffic_cop and traffic_manager ignore
proxy.config.local_state_dir
Key: TS-2448
URL: https://issues.apache.org/jira/browse/TS-2448
Project: Traffic Server
Issue Type: Bug
Components: Configuration, cop, Management
Reporter: James Peach
{{traffic_cop}} and {{traffic_manager}} ignore the
{{proxy.config.local_state_dir}} configuration variable.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Assigned] (TS-2271) Threaded plugin support with 3rd party libraries
[ https://issues.apache.org/jira/browse/TS-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-2271: --- Assignee: James Peach Yup. > Threaded plugin support with 3rd party libraries > > > Key: TS-2271 > URL: https://issues.apache.org/jira/browse/TS-2271 > Project: Traffic Server > Issue Type: Wish > Components: Plugins >Reporter: Heikki Hannikainen >Assignee: James Peach > Fix For: 4.2.0 > > > We have created an ATS plugin which links to a library (an existing one which > is widely deployed in our other products). That library *creates threads* and > *links with openssl*. It's not an option at this point to rework that library > to use ATS threading functions. > The library will, in the end, call a callback function provided by our ATS > plugin. That call happens from a thread created by the library (outside TS > and plugin code). That callback function will then re-enable a transaction. > There are two problems: > # The library creates threads, and then calls openssl in those threads, and > openssl in turn calls mutex/thread id functions provided by ATS > (*SSL_pthreads_thread_id*, *SSL_locking_callback*). The functions provided by > ATS bail out if they don't know about the threads of the 3rd-party library. > # The callback function called by the library needs to re-enable a > transaction. The *TSHttpTxnReenable* API function bails out if called from a > thread created by the 3rd-party library. > To work around the OpenSSL-in-threads issue I changed the callbacks to use > regular pthread functions directly. > [https://github.com/hessu/trafficserver/commit/34b8455518a3e8093d935412c03cfdd3cb5ea398] > To re-enable transactions I made *TSHttpTxnReenableFromThread* which doesn't > try to look up an EThread. That would fail and the server would quit. > https://github.com/hessu/trafficserver/commit/0038e9ff1584513fdf8dc96bdd7b2fe12f046fe3 > How does the ATS project feel about this use case (plugin with library which > uses threads)? Should ATS support it directly somehow? > I understand that the requirement might be pretty rare, and that the patches > are not something that should go in ATS as they are (especially the SSL > threading callbacks, it's now a bunch of almost-duplicate code). I'm just > publishing them to describe the workarounds and help discussion. We can live > with a fork with 3 patches on top. > I'd also be happy to hear about better workarounds. > TSHttpTxnReenableFromThread appears to have a measurable latency (~10ms). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (TS-2435) Broken links on download page
[ https://issues.apache.org/jira/browse/TS-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miles Libbey resolved TS-2435. -- Resolution: Fixed Its been pushed now. > Broken links on download page > - > > Key: TS-2435 > URL: https://issues.apache.org/jira/browse/TS-2435 > Project: Traffic Server > Issue Type: Bug >Reporter: Sebb >Assignee: Miles Libbey > Fix For: Docs > > > http://trafficserver.apache.org/downloads > has sig and hash links for older releases: > Archived (stable) Release -- 4.0.1 > Archived (stable) Release -- 3.2.4 > Archived (stable) Release -- 3.2.0 > This is good, but the links need to point to the archive server. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (TS-1533) make read_from_writer works in 3.0.x
[ https://issues.apache.org/jira/browse/TS-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1533. --- Resolution: Won't Fix Closing as won't fix, this works in 4.x. > make read_from_writer works in 3.0.x > > > Key: TS-1533 > URL: https://issues.apache.org/jira/browse/TS-1533 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.0.5 > Environment: all >Reporter: weijin >Assignee: weijin > Fix For: 3.0.6 > > > similar with TS-1433, this patch try to fix the bug that read_from_writer > always failed even if we enable read_from_writer, and it also fix a race > condition that may lead crash (to lock the write_vc after it was freed). need > reviews. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-1956) Under Heavy Load TS 3.3.4-dev can't (re)start
[
https://issues.apache.org/jira/browse/TS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1956:
--
Labels: Crash (was: )
> Under Heavy Load TS 3.3.4-dev can't (re)start
> -
>
> Key: TS-1956
> URL: https://issues.apache.org/jira/browse/TS-1956
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Tommy Lee
>Priority: Blocker
> Labels: Crash
> Fix For: 5.0.0
>
> Attachments: backtrace.log
>
>
> Hi,
> We run TS in forward mode, under REALLY HEAVY load. Currently we run version
> 3.3.2-dev without problems.
> But today, we tried to upgrade to version 3.3.4-dev without lucky.
> We've noticed that, if TS restarts, it enters in this Segfault Loop.
> Below are traffic.out logs with debug .*
> I'll try to debug with GDB too, but I cannot stop this server for too long,
> because of our operations.
> Thanks in advance.
>
> {code}
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fd9e0 on port 3128 as inbound transparent
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fdd00 on port 3128 as inbound transparent
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.563] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> [Jun 14 11:54:14.563] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.81.5:46089 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.101.4:41361 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.156.38:59164 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b06a5413700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c00] accepted connection from
> 10.202.81.5:46089 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.35.9:51533 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.201.20:10964 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b06a5615700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015a80] accepted connection from
> 10.200.156.38:59164 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_processor)
> NetProcessor::main_accept - port 3128,recv_bufsize 0, send_bufsize 262144,
> sockopt 0x0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.202.148.2:44203 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Marking
> accept server 0x20fe020 on port 3128 as inbound transparent
> [Jun 14 11:54:14.564] Server {0x2b06a5514700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015d20] accepted connection from
> 10.202.101.4:41361 transport type = 0
> [Jun 14 11:54:14.564] Server {0x2b06a5817700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c015540] accepted connection from
> 10.200.201.20:10964 transport type = 0NOTE: Traffic Server received Sig 11:
> Segmentation fault
> /usr/local/cache-3.3.4/bin/traffic_server - STACK TRACE:
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (http_tproxy) Listen
> port inbound transparency enabled.
> [Jun 14 11:54:14.564] Server {0x2b069d226500} DEBUG: (iocore_net_accept)
> Created accept thread #1 for port 3128
> NOTE: Traffic Server received Sig 11: Segmentation fault
> [Jun 14 11:54:14.564] Server {0x2b06a5716700} DEBUG: (http_seq)
> [HttpAccept:mainEvent 0x2b085c0157e0] accepted connection from
> 10.200.35.9:51533 transport type = 0/usr/local/cache-3.3.4/bin/traffic_server
> - STACK TRACE:
> [Jun 14 11:54:14.564] Server {0x2b085c120700} DEBUG: (iocore_net_server)
> Connection accepted [Server]. 10.200.131.24:65434 -> *Not IP address [0]*:0
> [Jun 14 11:54:14.564] Server {0x2b0850514700} DEBUG: (iocore_net_server)
>
[jira] [Resolved] (TS-2374) http_sm hung when all consumers aborted but the producer still alive
[ https://issues.apache.org/jira/browse/TS-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2374. --- Resolution: Fixed I think this is resolved? Closing. > http_sm hung when all consumers aborted but the producer still alive > > > Key: TS-2374 > URL: https://issues.apache.org/jira/browse/TS-2374 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: weijin > Fix For: 4.2.0 > > > HttpSM will kill_this when the tunnel is not alive (none of consumer alive, > nor the producer). But when the cache_vc (for write) is the only consumer of > the server_session, and the consumer is aborted because of write failed, the > httpsm hung. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2374) http_sm hung when all consumers aborted but the producer still alive
[ https://issues.apache.org/jira/browse/TS-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2374: -- Backport to Version: (was: 4.0.2) > http_sm hung when all consumers aborted but the producer still alive > > > Key: TS-2374 > URL: https://issues.apache.org/jira/browse/TS-2374 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: weijin >Assignee: weijin > Fix For: 4.2.0 > > > HttpSM will kill_this when the tunnel is not alive (none of consumer alive, > nor the producer). But when the cache_vc (for write) is the only consumer of > the server_session, and the consumer is aborted because of write failed, the > httpsm hung. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2271) Threaded plugin support with 3rd party libraries
[ https://issues.apache.org/jira/browse/TS-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2271: -- Fix Version/s: 4.2.0 > Threaded plugin support with 3rd party libraries > > > Key: TS-2271 > URL: https://issues.apache.org/jira/browse/TS-2271 > Project: Traffic Server > Issue Type: Wish > Components: Plugins >Reporter: Heikki Hannikainen > Fix For: 4.2.0 > > > We have created an ATS plugin which links to a library (an existing one which > is widely deployed in our other products). That library *creates threads* and > *links with openssl*. It's not an option at this point to rework that library > to use ATS threading functions. > The library will, in the end, call a callback function provided by our ATS > plugin. That call happens from a thread created by the library (outside TS > and plugin code). That callback function will then re-enable a transaction. > There are two problems: > # The library creates threads, and then calls openssl in those threads, and > openssl in turn calls mutex/thread id functions provided by ATS > (*SSL_pthreads_thread_id*, *SSL_locking_callback*). The functions provided by > ATS bail out if they don't know about the threads of the 3rd-party library. > # The callback function called by the library needs to re-enable a > transaction. The *TSHttpTxnReenable* API function bails out if called from a > thread created by the 3rd-party library. > To work around the OpenSSL-in-threads issue I changed the callbacks to use > regular pthread functions directly. > [https://github.com/hessu/trafficserver/commit/34b8455518a3e8093d935412c03cfdd3cb5ea398] > To re-enable transactions I made *TSHttpTxnReenableFromThread* which doesn't > try to look up an EThread. That would fail and the server would quit. > https://github.com/hessu/trafficserver/commit/0038e9ff1584513fdf8dc96bdd7b2fe12f046fe3 > How does the ATS project feel about this use case (plugin with library which > uses threads)? Should ATS support it directly somehow? > I understand that the requirement might be pretty rare, and that the patches > are not something that should go in ATS as they are (especially the SSL > threading callbacks, it's now a bunch of almost-duplicate code). I'm just > publishing them to describe the workarounds and help discussion. We can live > with a fork with 3 patches on top. > I'd also be happy to hear about better workarounds. > TSHttpTxnReenableFromThread appears to have a measurable latency (~10ms). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (TS-2271) Threaded plugin support with 3rd party libraries
[ https://issues.apache.org/jira/browse/TS-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854610#comment-13854610 ] Leif Hedstrom commented on TS-2271: --- Cool. Sounds like we have consensus? James, would you like to shepherd this? > Threaded plugin support with 3rd party libraries > > > Key: TS-2271 > URL: https://issues.apache.org/jira/browse/TS-2271 > Project: Traffic Server > Issue Type: Wish > Components: Plugins >Reporter: Heikki Hannikainen > Fix For: 4.2.0 > > > We have created an ATS plugin which links to a library (an existing one which > is widely deployed in our other products). That library *creates threads* and > *links with openssl*. It's not an option at this point to rework that library > to use ATS threading functions. > The library will, in the end, call a callback function provided by our ATS > plugin. That call happens from a thread created by the library (outside TS > and plugin code). That callback function will then re-enable a transaction. > There are two problems: > # The library creates threads, and then calls openssl in those threads, and > openssl in turn calls mutex/thread id functions provided by ATS > (*SSL_pthreads_thread_id*, *SSL_locking_callback*). The functions provided by > ATS bail out if they don't know about the threads of the 3rd-party library. > # The callback function called by the library needs to re-enable a > transaction. The *TSHttpTxnReenable* API function bails out if called from a > thread created by the 3rd-party library. > To work around the OpenSSL-in-threads issue I changed the callbacks to use > regular pthread functions directly. > [https://github.com/hessu/trafficserver/commit/34b8455518a3e8093d935412c03cfdd3cb5ea398] > To re-enable transactions I made *TSHttpTxnReenableFromThread* which doesn't > try to look up an EThread. That would fail and the server would quit. > https://github.com/hessu/trafficserver/commit/0038e9ff1584513fdf8dc96bdd7b2fe12f046fe3 > How does the ATS project feel about this use case (plugin with library which > uses threads)? Should ATS support it directly somehow? > I understand that the requirement might be pretty rare, and that the patches > are not something that should go in ATS as they are (especially the SSL > threading callbacks, it's now a bunch of almost-duplicate code). I'm just > publishing them to describe the workarounds and help discussion. We can live > with a fork with 3 patches on top. > I'd also be happy to hear about better workarounds. > TSHttpTxnReenableFromThread appears to have a measurable latency (~10ms). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2421) HostDB creates files FOR THE DEVIL
[
https://issues.apache.org/jira/browse/TS-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2421:
--
Fix Version/s: 4.2.0
> HostDB creates files FOR THE DEVIL
> --
>
> Key: TS-2421
> URL: https://issues.apache.org/jira/browse/TS-2421
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS, Security
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> from iocore/hostdb/MultiCache.cc:
> {code}
> // XXX: Shouldn't that be 0664?
> //
> if ((fd =::open(p, O_CREAT | O_WRONLY | O_TRUNC, 0666)) >= 0) {
> {code}
> Yes. Yes it should.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (TS-2440) ATS 3.2.0 keeps restarting after adding a node to the cluster (not the same as TS-1511)
[
https://issues.apache.org/jira/browse/TS-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854609#comment-13854609
]
Leif Hedstrom commented on TS-2440:
---
Is this also an issue with v4.x ? Or is it specific to v3.2 ?
> ATS 3.2.0 keeps restarting after adding a node to the cluster (not the same
> as TS-1511)
> ---
>
> Key: TS-2440
> URL: https://issues.apache.org/jira/browse/TS-2440
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Clustering
>Reporter: Kamil Abboud
>
> Hi all,
> We have two nodes installed with ATS3.2.0 running on RHEL6.2.
> When we start the second node (in full clustering mode) the system works for
> ~5-10 minutes and the traffic server process crashes giving the following
> stacktrace:
> {code}
> #0 0x00360cd372a0 in __memcpy_ssse3 () from /lib64/libc.so.6
> #1 0x005b3521 in HdrHeap::marshal(char*, int) ()
> #2 0x005b73a1 in HTTPInfo::marshal(char*, int) ()
> #3 0x005fda19 in CacheContinuation::replyOpEvent(int, VConnection*)
> ()
> #4 0x005fa677 in CacheContinuation::VCdataRead(int, VIO*) ()
> #5 0x0064683c in CacheVC::openReadMain(int, Event*) ()
> #6 0x0064520b in CacheVC::callcont ()
> #7 0x00648896 in CacheVC::openReadStartEarliest(int, Event*) ()
> #8 0x0062540d in CacheVC::handleReadDone(int, Event*) ()
> #9 0x0062a295 in AIOCallbackInternal::io_complete(int, void*) ()
> #10 0x00696c04 in EThread::process_event(Event*, int) ()
> #11 0x0069767b in EThread::execute() ()
> #12 0x00695bd2 in spawn_thread_internal(void*) ()
> #13 0x00360d0077f1 in start_thread () from /lib64/libpthread.so.0
> #14 0x00360cce570d in clone () from /lib64/libc.so.6
> {code}
> Please note that the system we are working with has the following Fixes on it:
> - TS-1424
> - TS-1151
> - TS-1580
> - TS-2092
> - TS-2264
> Thanks,
> Kamil
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (TS-2433) Size threshold for SSL request
[ https://issues.apache.org/jira/browse/TS-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854604#comment-13854604 ] Leif Hedstrom commented on TS-2433: --- [~sunwei] Are you going to work on this? If so, assign it to you, and perhaps set a Fix Version (v4.2.0 is scheduled for February 2014, 5.0 for May 2014). > Size threshold for SSL request > -- > > Key: TS-2433 > URL: https://issues.apache.org/jira/browse/TS-2433 > Project: Traffic Server > Issue Type: Task >Reporter: Wei Sun > > A size threshold is expected for client request over SSL, if the max > requested data(SSL_read) exceeds the threshold, close the connection. > Default: no size limitation. We have this use case when using stunnel, expect > to have the same functionality in ATS. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (TS-2431) Add SPDY supporting to ATS
[ https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854603#comment-13854603 ] Leif Hedstrom commented on TS-2431: --- What's a reasonable target release for this? I'm hoping v5.0.0? :) > Add SPDY supporting to ATS > -- > > Key: TS-2431 > URL: https://issues.apache.org/jira/browse/TS-2431 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: Yunkai Zhang > > I'm working on it. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2446) Document how to document
[ https://issues.apache.org/jira/browse/TS-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2446: -- Fix Version/s: Docs > Document how to document > > > Key: TS-2446 > URL: https://issues.apache.org/jira/browse/TS-2446 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Miles Libbey > Fix For: Docs > > > Our documentation system has a very large learning curve. Writers need to > learn reStructured text and Sphinx and our unique conventions/hooks/whatever. > Without documentation, writers have to view many doc source code to attempt > to comprehend what those conventions are. Similarly, these conventions > prevent standard reStructured text from rendering cleanly (for instance, > http://rst.ninjs.org/ shows tons of errors for any given doc file we have -- > http://rst.ninjs.org/?n=aa8dc0bc3e337df7a2b5e14757debc81&theme=basic). > Lastly, we should provide explicit, step by step instructions on how to get a > local version of sphinx up and running that a non developer can follow. > We need to document: > - what are all the trafficserver specific hooks/conventions? > - when should they be used? > - how they should be used? > - how to preview a change without pushing to production? > For instance, Igor noted as part of reviewing > https://issues.apache.org/jira/browse/TS-2183 : > "General: all of the CAPSLOCK words should be put in the glossary" > - how does one mark a term in the doc as having a glossary item? > - where (what file) would the item's definition go? > - what is the structure of that definition? > Some other specific markup that needs explanation: > :ts:cv: > ts:const: > ts:git: > Similarly, it's also not clear to me when to choose markup like > `proxy.config.http.server_ports`_ versus :index: vs :ts:cv: vs :ref: etc. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2441) Typos on download page
[ https://issues.apache.org/jira/browse/TS-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2441: -- Fix Version/s: Docs > Typos on download page > -- > > Key: TS-2441 > URL: https://issues.apache.org/jira/browse/TS-2441 > Project: Traffic Server > Issue Type: Bug > Components: Web site >Reporter: Sebb >Assignee: Miles Libbey > Fix For: Docs > > > The download page [1] has a section headed: > "Archived v4.0 Release -- 4.0.2" > This contains the text: > "Apache Traffic Server 4.0.1 was released on October 14, 2013. [PGP] [MD5] > [SHA1] " > 4.0.1 should be 4.0.2 > Also, near the top of the page, it says: > "For details on upgrading to v4.0.2, see these instructions". > The version looks wrong. > [1] http://trafficserver.apache.org/downloads -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2441) Typos on download page
[ https://issues.apache.org/jira/browse/TS-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2441: -- Assignee: Miles Libbey (was: Igor Galić) > Typos on download page > -- > > Key: TS-2441 > URL: https://issues.apache.org/jira/browse/TS-2441 > Project: Traffic Server > Issue Type: Bug > Components: Web site >Reporter: Sebb >Assignee: Miles Libbey > Fix For: Docs > > > The download page [1] has a section headed: > "Archived v4.0 Release -- 4.0.2" > This contains the text: > "Apache Traffic Server 4.0.1 was released on October 14, 2013. [PGP] [MD5] > [SHA1] " > 4.0.1 should be 4.0.2 > Also, near the top of the page, it says: > "For details on upgrading to v4.0.2, see these instructions". > The version looks wrong. > [1] http://trafficserver.apache.org/downloads -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (TS-2441) Typos on download page
[ https://issues.apache.org/jira/browse/TS-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854602#comment-13854602 ] Leif Hedstrom commented on TS-2441: --- Moving to Miles, this might even be a dupe ? > Typos on download page > -- > > Key: TS-2441 > URL: https://issues.apache.org/jira/browse/TS-2441 > Project: Traffic Server > Issue Type: Bug > Components: Web site >Reporter: Sebb >Assignee: Miles Libbey > Fix For: Docs > > > The download page [1] has a section headed: > "Archived v4.0 Release -- 4.0.2" > This contains the text: > "Apache Traffic Server 4.0.1 was released on October 14, 2013. [PGP] [MD5] > [SHA1] " > 4.0.1 should be 4.0.2 > Also, near the top of the page, it says: > "For details on upgrading to v4.0.2, see these instructions". > The version looks wrong. > [1] http://trafficserver.apache.org/downloads -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2435) Broken links on download page
[ https://issues.apache.org/jira/browse/TS-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2435: -- Fix Version/s: Docs > Broken links on download page > - > > Key: TS-2435 > URL: https://issues.apache.org/jira/browse/TS-2435 > Project: Traffic Server > Issue Type: Bug >Reporter: Sebb >Assignee: Miles Libbey > Fix For: Docs > > > http://trafficserver.apache.org/downloads > has sig and hash links for older releases: > Archived (stable) Release -- 4.0.1 > Archived (stable) Release -- 3.2.4 > Archived (stable) Release -- 3.2.0 > This is good, but the links need to point to the archive server. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (TS-2447) Cache fails to load / initialize, seems stuck on directory entry cleanup
[
https://issues.apache.org/jira/browse/TS-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2447:
--
Fix Version/s: 4.2.0
> Cache fails to load / initialize, seems stuck on directory entry cleanup
>
>
> Key: TS-2447
> URL: https://issues.apache.org/jira/browse/TS-2447
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Leif Hedstrom
> Fix For: 4.2.0
>
>
> We had an issue where a number of machines would not startup properly. They
> get stuck on reading / initializing the cache. It initializes the caches with
> {code}
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 0:
> Vol Blocks: 1: Free space: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
> 0 Size: 62509342
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
> No: 0 Size: 62509342 Free: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 1:
> Vol Blocks: 1: Free space: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
> 0 Size: 62509342
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
> No: 0 Size: 62509342 Free: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 2:
> Vol Blocks: 1: Free space: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
> 0 Size: 62509342
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
> No: 0 Size: 62509342 Free: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 3:
> Vol Blocks: 1: Free space: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
> 0 Size: 62509342
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
> No: 0 Size: 62509342 Free: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 4:
> Vol Blocks: 1: Free space: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
> 0 Size: 62509342
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
> No: 0 Size: 62509342 Free: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 5:
> Vol Blocks: 1: Free space: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
> 0 Size: 62509342
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
> No: 0 Size: 62509342 Free: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 6:
> Vol Blocks: 1: Free space: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol:
> 0 Size: 62509342
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
> No: 0 Size: 62509342 Free: 0
> [Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) Cache::open
> - proxy.config.cache.min_average_object_size = 65536
> [Dec 20 16:45:40.198] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
> 78135296 directory bytes for a 512076529664 byte volume (0.015259%)
> [Dec 20 16:45:40.201] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
> 78135296 directory bytes for a 512076529664 byte volume (0.015259%)
> [Dec 20 16:45:40.204] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
> 78135296 directory bytes for a 512076529664 byte volume (0.015259%)
> [Dec 20 16:45:40.208] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
> 78135296 directory bytes for a 512076529664 byte volume (0.015259%)
> [Dec 20 16:45:40.213] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
> 78135296 directory bytes for a 512076529664 byte volume (0.015259%)
> [Dec 20 16:45:40.219] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
> 78135296 directory bytes for a 512076529664 byte volume (0.015259%)
> [Dec 20 16:45:40.224] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
> 78135296 directory bytes for a 512076529664 byte volume (0.015259%)
> {code}
> After this, it enters a stage where it’s doing a *lot* of dir_clean events:
> {code}
> [Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
> 0x7f3edcd6f028 tag 0 boffset 0 b 0x7f3edcd6f028 p (nil) l 1
> [Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
> 0x7f3edcd6f050 tag 0 boffset 0 b 0x7f3edcd6f050 p (nil) l 1
> [Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
> 0x7f3edcd6f078 tag 0 boffset 0 b 0x7f3edcd6f078 p (nil) l 1
> [Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
> 0x7f3edcd6f0a0 tag 0 boffset 0 b 0x7f3edcd6f0a0 p (nil) l 1
> [Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
> 0x7f3edcd6f0c8 tag 0 bo
[jira] [Created] (TS-2447) Cache fails to load / initialize, seems stuck on directory entry cleanup
Leif Hedstrom created TS-2447:
-
Summary: Cache fails to load / initialize, seems stuck on
directory entry cleanup
Key: TS-2447
URL: https://issues.apache.org/jira/browse/TS-2447
Project: Traffic Server
Issue Type: Bug
Components: Cache
Reporter: Leif Hedstrom
We had an issue where a number of machines would not startup properly. They get
stuck on reading / initializing the cache. It initializes the caches with
{code}
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 0:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol: 0
Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 1:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol: 0
Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 2:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol: 0
Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 3:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol: 0
Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 4:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol: 0
Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 5:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol: 0
Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting) Disk: 6:
Vol Blocks: 1: Free space: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Vol: 0
Size: 62509342
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_hosting)Block
No: 0 Size: 62509342 Free: 0
[Dec 20 16:45:40.195] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) Cache::open -
proxy.config.cache.min_average_object_size = 65536
[Dec 20 16:45:40.198] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.201] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.204] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.208] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.213] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.219] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
[Dec 20 16:45:40.224] Server {0x7f3f2f4ef7e0} DEBUG: (cache_init) allocating
78135296 directory bytes for a 512076529664 byte volume (0.015259%)
{code}
After this, it enters a stage where it’s doing a *lot* of dir_clean events:
{code}
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f028 tag 0 boffset 0 b 0x7f3edcd6f028 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f050 tag 0 boffset 0 b 0x7f3edcd6f050 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f078 tag 0 boffset 0 b 0x7f3edcd6f078 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0a0 tag 0 boffset 0 b 0x7f3edcd6f0a0 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0c8 tag 0 boffset 0 b 0x7f3edcd6f0c8 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f0f0 tag 0 boffset 0 b 0x7f3edcd6f0f0 p (nil) l 1
[Dec 20 16:45:40.314] Server {0x7f3f26f91700} DEBUG: (dir_clean) cleaning
0x7f3edcd6f140 tag 0 boffset 0 b 0x7f3edcd6f140 p (nil) l 1
{code}
This goes on for a while, until it reaches some state where one entry i
[jira] [Resolved] (TS-2351) Range request crash in 4.1.x
[
https://issues.apache.org/jira/browse/TS-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2351.
---
Resolution: Fixed
I'm going to close this for now. If you experience a crash with v4.1.2 or
master again, please open a new bug.
> Range request crash in 4.1.x
>
>
> Key: TS-2351
> URL: https://issues.apache.org/jira/browse/TS-2351
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.1.2
>Reporter: David Carlin
>Assignee: Leif Hedstrom
>Priority: Blocker
> Fix For: 4.2.0
>
>
> I am seeing the following crash using the 4.1.0 and 4.1.1 artifacts posted on
> the mailing list.
> One host I upgraded crashed immediately. Others take hours/days for crash to
> appear.
> {noformat}
> #0 0x00544e59 in
> HttpTransact::change_response_header_because_of_range_request
> (s=0x2b2ff3f44288, header=0x2b2ff3f44968) at HttpTransact.cc:8692
> #1 0x00545190 in HttpTransact::handle_content_length_header
> (s=0x2b2ff3f44288, header=0x2b2ff3f44968, base=)
> at HttpTransact.cc:6559
> #2 0x0054c963 in HttpTransact::build_response (s=0x2b2ff3f44288,
> base_response=0x2b2ff3f44a28, outgoing_response=0x2b2ff3f44968,
> outgoing_version=, status_code=HTTP_STATUS_NONE,
> reason_phrase=0x6bf28c "None") at HttpTransact.cc:7682
> #3 0x0054d2e0 in build_response (s=0x2b2ff3f44288) at
> HttpTransact.cc:7644
> #4 HttpTransact::handle_transform_ready (s=0x2b2ff3f44288) at
> HttpTransact.cc:4577
> #5 0x0051bfe8 in HttpSM::call_transact_and_set_next_state
> (this=0x2b2ff3f44220, f=) at HttpSM.cc:6767
> #6 0x005317ed in HttpSM::state_response_wait_for_transform_read
> (this=0x2b2ff3f44220, event=2000, data=0x2b3168082460) at HttpSM.cc:1210
> #7 0x005306e8 in HttpSM::main_handler (this=0x2b2ff3f44220,
> event=2000, data=0x2b3168082460) at HttpSM.cc:2530
> #8 0x004e9406 in handleEvent (this=0x2b31680823d8, event=1) at
> ../iocore/eventsystem/I_Continuation.h:146
> #9 TransformTerminus::handle_event (this=0x2b31680823d8, event=1) at
> Transform.cc:173
> #10 0x006a636f in handleEvent (this=0x2b2fda6cc010, e=0x2b315c060c60,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2b2fda6cc010, e=0x2b315c060c60,
> calling_code=1) at UnixEThread.cc:145
> #12 0x006a6eeb in EThread::execute (this=0x2b2fda6cc010) at
> UnixEThread.cc:196
> #13 0x004c6ae4 in main (argv=) at Main.cc:1686
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/localbin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x3aec80f500)[0x2af3d029a500]
> /usr/localbin/traffic_server(_ZN12HttpTransact47change_response_header_because_of_range_requestEPNS_5StateEP7HTTPHdr+0x219)[0x544e59]
> /usr/localbin/traffic_server(_ZN12HttpTransact28handle_content_length_headerEPNS_5StateEP7HTTPHdrS3_+0x280)[0x545190]
> /usr/localbin/traffic_server(_ZN12HttpTransact14build_responseEPNS_5StateEP7HTTPHdrS3_11HTTPVersion10HTTPStatusPKc+0x3e3)[0x54c963]
> /usr/localbin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x70)[0x54d2e0]
> /usr/localbin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x51bfe8]
> /usr/localbin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x5317ed]
> /usr/localbin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5306e8]
> /usr/localbin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x1d6)[0x4e9406]
> /usr/localbin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a636f]
> /usr/localbin/traffic_server(_ZN7EThread7executeEv+0x63b)[0x6a6eeb]
> /usr/localbin/traffic_server[0x6a520a]
> /lib64/libpthread.so.0(+0x3aec807851)[0x2af3d0292851]
> /lib64/libc.so.6(clone+0x6d)[0x3aec4e890d]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (TS-2351) Range request crash in 4.1.x
[
https://issues.apache.org/jira/browse/TS-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2351:
--
Backport to Version: (was: 4.1.2)
> Range request crash in 4.1.x
>
>
> Key: TS-2351
> URL: https://issues.apache.org/jira/browse/TS-2351
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.1.2
>Reporter: David Carlin
>Assignee: Leif Hedstrom
>Priority: Blocker
> Fix For: 4.1.2, 4.2.0
>
>
> I am seeing the following crash using the 4.1.0 and 4.1.1 artifacts posted on
> the mailing list.
> One host I upgraded crashed immediately. Others take hours/days for crash to
> appear.
> {noformat}
> #0 0x00544e59 in
> HttpTransact::change_response_header_because_of_range_request
> (s=0x2b2ff3f44288, header=0x2b2ff3f44968) at HttpTransact.cc:8692
> #1 0x00545190 in HttpTransact::handle_content_length_header
> (s=0x2b2ff3f44288, header=0x2b2ff3f44968, base=)
> at HttpTransact.cc:6559
> #2 0x0054c963 in HttpTransact::build_response (s=0x2b2ff3f44288,
> base_response=0x2b2ff3f44a28, outgoing_response=0x2b2ff3f44968,
> outgoing_version=, status_code=HTTP_STATUS_NONE,
> reason_phrase=0x6bf28c "None") at HttpTransact.cc:7682
> #3 0x0054d2e0 in build_response (s=0x2b2ff3f44288) at
> HttpTransact.cc:7644
> #4 HttpTransact::handle_transform_ready (s=0x2b2ff3f44288) at
> HttpTransact.cc:4577
> #5 0x0051bfe8 in HttpSM::call_transact_and_set_next_state
> (this=0x2b2ff3f44220, f=) at HttpSM.cc:6767
> #6 0x005317ed in HttpSM::state_response_wait_for_transform_read
> (this=0x2b2ff3f44220, event=2000, data=0x2b3168082460) at HttpSM.cc:1210
> #7 0x005306e8 in HttpSM::main_handler (this=0x2b2ff3f44220,
> event=2000, data=0x2b3168082460) at HttpSM.cc:2530
> #8 0x004e9406 in handleEvent (this=0x2b31680823d8, event=1) at
> ../iocore/eventsystem/I_Continuation.h:146
> #9 TransformTerminus::handle_event (this=0x2b31680823d8, event=1) at
> Transform.cc:173
> #10 0x006a636f in handleEvent (this=0x2b2fda6cc010, e=0x2b315c060c60,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2b2fda6cc010, e=0x2b315c060c60,
> calling_code=1) at UnixEThread.cc:145
> #12 0x006a6eeb in EThread::execute (this=0x2b2fda6cc010) at
> UnixEThread.cc:196
> #13 0x004c6ae4 in main (argv=) at Main.cc:1686
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/localbin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x3aec80f500)[0x2af3d029a500]
> /usr/localbin/traffic_server(_ZN12HttpTransact47change_response_header_because_of_range_requestEPNS_5StateEP7HTTPHdr+0x219)[0x544e59]
> /usr/localbin/traffic_server(_ZN12HttpTransact28handle_content_length_headerEPNS_5StateEP7HTTPHdrS3_+0x280)[0x545190]
> /usr/localbin/traffic_server(_ZN12HttpTransact14build_responseEPNS_5StateEP7HTTPHdrS3_11HTTPVersion10HTTPStatusPKc+0x3e3)[0x54c963]
> /usr/localbin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x70)[0x54d2e0]
> /usr/localbin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x51bfe8]
> /usr/localbin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x5317ed]
> /usr/localbin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5306e8]
> /usr/localbin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x1d6)[0x4e9406]
> /usr/localbin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a636f]
> /usr/localbin/traffic_server(_ZN7EThread7executeEv+0x63b)[0x6a6eeb]
> /usr/localbin/traffic_server[0x6a520a]
> /lib64/libpthread.so.0(+0x3aec807851)[0x2af3d0292851]
> /lib64/libc.so.6(clone+0x6d)[0x3aec4e890d]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (TS-2351) Range request crash in 4.1.x
[
https://issues.apache.org/jira/browse/TS-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2351:
--
Fix Version/s: 4.1.2
> Range request crash in 4.1.x
>
>
> Key: TS-2351
> URL: https://issues.apache.org/jira/browse/TS-2351
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Affects Versions: 4.1.2
>Reporter: David Carlin
>Assignee: Leif Hedstrom
>Priority: Blocker
> Fix For: 4.1.2, 4.2.0
>
>
> I am seeing the following crash using the 4.1.0 and 4.1.1 artifacts posted on
> the mailing list.
> One host I upgraded crashed immediately. Others take hours/days for crash to
> appear.
> {noformat}
> #0 0x00544e59 in
> HttpTransact::change_response_header_because_of_range_request
> (s=0x2b2ff3f44288, header=0x2b2ff3f44968) at HttpTransact.cc:8692
> #1 0x00545190 in HttpTransact::handle_content_length_header
> (s=0x2b2ff3f44288, header=0x2b2ff3f44968, base=)
> at HttpTransact.cc:6559
> #2 0x0054c963 in HttpTransact::build_response (s=0x2b2ff3f44288,
> base_response=0x2b2ff3f44a28, outgoing_response=0x2b2ff3f44968,
> outgoing_version=, status_code=HTTP_STATUS_NONE,
> reason_phrase=0x6bf28c "None") at HttpTransact.cc:7682
> #3 0x0054d2e0 in build_response (s=0x2b2ff3f44288) at
> HttpTransact.cc:7644
> #4 HttpTransact::handle_transform_ready (s=0x2b2ff3f44288) at
> HttpTransact.cc:4577
> #5 0x0051bfe8 in HttpSM::call_transact_and_set_next_state
> (this=0x2b2ff3f44220, f=) at HttpSM.cc:6767
> #6 0x005317ed in HttpSM::state_response_wait_for_transform_read
> (this=0x2b2ff3f44220, event=2000, data=0x2b3168082460) at HttpSM.cc:1210
> #7 0x005306e8 in HttpSM::main_handler (this=0x2b2ff3f44220,
> event=2000, data=0x2b3168082460) at HttpSM.cc:2530
> #8 0x004e9406 in handleEvent (this=0x2b31680823d8, event=1) at
> ../iocore/eventsystem/I_Continuation.h:146
> #9 TransformTerminus::handle_event (this=0x2b31680823d8, event=1) at
> Transform.cc:173
> #10 0x006a636f in handleEvent (this=0x2b2fda6cc010, e=0x2b315c060c60,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2b2fda6cc010, e=0x2b315c060c60,
> calling_code=1) at UnixEThread.cc:145
> #12 0x006a6eeb in EThread::execute (this=0x2b2fda6cc010) at
> UnixEThread.cc:196
> #13 0x004c6ae4 in main (argv=) at Main.cc:1686
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/localbin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0x3aec80f500)[0x2af3d029a500]
> /usr/localbin/traffic_server(_ZN12HttpTransact47change_response_header_because_of_range_requestEPNS_5StateEP7HTTPHdr+0x219)[0x544e59]
> /usr/localbin/traffic_server(_ZN12HttpTransact28handle_content_length_headerEPNS_5StateEP7HTTPHdrS3_+0x280)[0x545190]
> /usr/localbin/traffic_server(_ZN12HttpTransact14build_responseEPNS_5StateEP7HTTPHdrS3_11HTTPVersion10HTTPStatusPKc+0x3e3)[0x54c963]
> /usr/localbin/traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x70)[0x54d2e0]
> /usr/localbin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x28)[0x51bfe8]
> /usr/localbin/traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0xed)[0x5317ed]
> /usr/localbin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5306e8]
> /usr/localbin/traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x1d6)[0x4e9406]
> /usr/localbin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a636f]
> /usr/localbin/traffic_server(_ZN7EThread7executeEv+0x63b)[0x6a6eeb]
> /usr/localbin/traffic_server[0x6a520a]
> /lib64/libpthread.so.0(+0x3aec807851)[0x2af3d0292851]
> /lib64/libc.so.6(clone+0x6d)[0x3aec4e890d]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (TS-32) Fix ICP
[
https://issues.apache.org/jira/browse/TS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gota Adachi updated TS-32:
--
Attachment: TS-32-icp-multicast-3.2.x.diff
TS-32-segfault-workaround.diff
TS-32-icp-basic-3.2.x.diff
I attached 3 patches:
This fix is being tested with trafficserver-3.2.0 and 4.0.2
on CentOS 6.5
h5. Patch 1/3: TS-32-icp-basic-3.2.x.diff
This patch minimum FIX to let ICP work.
Fixed an error on access to class member that was not initialized and
restored former implementation based on a change in TS-320.
And commented out the forced termination code in
UDPReadContinuation::readPollEvent().
Please tell me if you know what seems to be the problem in this
implementation.
h5. Patch 2/3: TS-32-segfault-workaround.diff
After applying this patch, I encountered a Segfault problem in
traffic_server, this issue looks like the one on [TS-1219].
While debugging, I found a buffer overrun problem in
PollDescriptor::alloc().
I confirmed in GDB that an allocated memory area for ioBufAllocator was
broken by this method.
This is an minimum workaround to prevent Segfault, but we should work on
a proper FIX.
h5. Patch 3/3: TS-32-icp-multicast-3.2.x.diff (depends on Patch 1/3)
This is a FIX to perform multicast ICP communication. On my testing
servers, I provide 2 NICs to my VM as eth0 and eth1.
TS was not using eth1 to send ICP packets so i fixed it.
\\
There are some different parts from the documents and the settings. An
error ocurred while inserting a localhost configuration in icp.config.
And also, after a HIT ICP response, TS transfer a request to the peer
server with a remaped URL causing a 404 error.
To solve this we should add a record to remap.config as below:
{code:title=remap.config|borderStyle=solid}
map http://192.168.36.22:8080/ http://1.2.3.4/
reverse_map http://1.2.3.4 http://192.168.36.22/
# add
map http://1.2.3.4/ http://1.2.3.4/
{code}
I'm continuing with my tests and TS seems to be working fine on my servers.
(But beacuase I don't know what ther real specifications are, I'm not
completely sure if what I'm doing is right...)
Please let me know your opinion about this patch.
Best regards.
> Fix ICP
> ---
>
> Key: TS-32
> URL: https://issues.apache.org/jira/browse/TS-32
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.0
>Reporter: Miles Libbey
>Assignee: Zhao Yongming
> Fix For: sometime
>
> Attachments: TS-32-icp-basic-3.2.x.diff,
> TS-32-icp-multicast-3.2.x.diff, TS-32-segfault-workaround.diff
>
>
> {color:red}
> ICP is broken in all the releases and master, but we have options for that:
> inter-colo peering to use the parent.config, local network peering to use the
> cluster.
> refer to the official docutments for parent.config and cluster howto.
> {color}
> http://icp.ircache.net/
> The ICP implementation in Traffic Server broke when epoll() was introduced.
> Its still an interesting and used feature in caches:
> - when a caching layer of several boxes are used ICP helps to reduce
> disparities when a client is not routed to the same cache on subsequent
> requests
> - after a restart, it can help reduce the time spent in a cold cache situation
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
