[jira] [Work started] (TS-845) invalid setting of proxy.config.cluster.ethernet_interface will prevent traffc_manager from starting
[
https://issues.apache.org/jira/browse/TS-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-845 started by Zhao Yongming.
invalid setting of proxy.config.cluster.ethernet_interface will prevent
traffc_manager from starting
Key: TS-845
URL: https://issues.apache.org/jira/browse/TS-845
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.1.0, 3.0.0
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Critical
Labels: cluster, network
Fix For: 3.1.0
when you set an invalid interface in proxy.config.cluster.ethernet_interface,
it will just crash.
{code}
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL:
[LocalManager::initCCom] Unable to find network interface eth5. Exiting...
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL: (last system error 2:
No such file or directory)
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-845) invalid setting of proxy.config.cluster.ethernet_interface will prevent traffc_manager from starting
invalid setting of proxy.config.cluster.ethernet_interface will prevent
traffc_manager from starting
Key: TS-845
URL: https://issues.apache.org/jira/browse/TS-845
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.0.0, 3.1.0
Reporter: Zhao Yongming
Priority: Critical
Fix For: 3.1.0
when you set an invalid interface in proxy.config.cluster.ethernet_interface,
it will just crash.
{code}
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL: [LocalManager::initCCom]
Unable to find network interface eth5. Exiting...
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL: (last system error 2:
No such file or directory)
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-831) dd elements need to be on line to avoid p elements
[
https://issues.apache.org/jira/browse/TS-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13051898#comment-13051898
]
Igor Galić commented on TS-831:
---
I can monkey through the docs and change all the occurrences - but for some
this won't be possible: What do we do when the description doesn't fit in one
line? When it's multiple paragraphs long containing code examples etc..?
n.b.: The choice of Definition lists was a gut decision - if we find a better
way to represent things, we should not not hesitate to change it.
dd elements need to be on line to avoid p elements
--
Key: TS-831
URL: https://issues.apache.org/jira/browse/TS-831
Project: Traffic Server
Issue Type: Bug
Components: Documentation
Affects Versions: Doc 3.0
Reporter: Miles Libbey
Assignee: Igor Galić
In looking at the styling for
http://trafficserver.staging.apache.org/docs/trunk/admin/configuration-files/records.config
there are several dd elements that get P elements around the text, for no
apparent reason.
For instance,
*`proxy.config.watch_script`* {#proxy.config.watch_script}
: `STRING`
: Default: `traffic_cop`
: The name of the executable that runs the `traffic_cop` process.
does not get a p element (as expected):
dt
id=proxy.config.watch_scriptemcodeproxy.config.watch_script/code/em/dt
ddcodeSTRING/code/dd
ddDefault: codetraffic_cop/code/dd
ddThe name of the executable that runs the codetraffic_cop/code
process./dd
but
*`proxy.config.admin.number_config_bak`*
{#proxy.config.admin.number_config_bak}
: `INT`
: Default: `3`
: The maximum number of copies of rolled configuration files to
keep.
does:
dt
id=proxy.config.admin.number_config_bakemcodeproxy.config.admin.number_config_bak/code/em/dt
dd
pcodeINT/code/p
/dd
dd
pDefault: code3/code/p
/dd
dd
pThe maximum number of copies of rolled configuration files to
keep./p
/dd
Hypothesis is that if the last line:
: The maximum number of copies of rolled configuration files to
keep.
was instead on 1 line
: The maximum number of copies of rolled configuration files to keep.
there would not be a P elements.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-826) TSHttpTxnErrorBodySet() can leak memory
[ https://issues.apache.org/jira/browse/TS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Bardwell updated TS-826: Attachment: ebs.diff Patch based on what TSHttpTxnServerRequestBodySet does. TSHttpTxnErrorBodySet() can leak memory --- Key: TS-826 URL: https://issues.apache.org/jira/browse/TS-826 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 Reporter: William Bardwell Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.0 Attachments: ebs.diff TSHttpTxnErrorBodySet() sets HttpSM::t_state.internal_msg_buffer without freeing any old contents in there. There can be an error message in that if you have a request with a bad hostname and you let the transaction get past DNS lookup. Instead it should free the contents, or there should be another field that it sets and nothing else does. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-826) TSHttpTxnErrorBodySet() can leak memory
[ https://issues.apache.org/jira/browse/TS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-826: - Backport to Version: 3.0.1 TSHttpTxnErrorBodySet() can leak memory --- Key: TS-826 URL: https://issues.apache.org/jira/browse/TS-826 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 Reporter: William Bardwell Assignee: Leif Hedstrom Priority: Minor Fix For: 3.1.0 Attachments: ebs.diff TSHttpTxnErrorBodySet() sets HttpSM::t_state.internal_msg_buffer without freeing any old contents in there. There can be an error message in that if you have a request with a bad hostname and you let the transaction get past DNS lookup. Instead it should free the contents, or there should be another field that it sets and nothing else does. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-846) Remap processor options could be integrated to a single option
Remap processor options could be integrated to a single option -- Key: TS-846 URL: https://issues.apache.org/jira/browse/TS-846 Project: Traffic Server Issue Type: Improvement Components: Configuration Affects Versions: 3.0.0 Reporter: Eric Balsa Assignee: Eric Balsa Priority: Minor Fix For: 3.1.0 TS_ReadConfigInteger(use_separate_thread, proxy.config.remap.use_remap_processor); and TS_ReadConfigInteger(num_remap_threads, proxy.config.remap.num_remap_threads); should be changed to a single config TS_ReadConfigInteger(num_remap_threads, proxy.config.remap.num_remap_threads); whereby a setting of 0 would indicate not to use a separate thread(s) for remapping. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-847) Forward proxy: Can't create SSL connection to older Subversion Servers.
Forward proxy: Can't create SSL connection to older Subversion Servers.
---
Key: TS-847
URL: https://issues.apache.org/jira/browse/TS-847
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.0, 3.1.0
Reporter: Igor Galić
When trying to access older Subversion (1.6.9, 1.5.1 verified) servers through
SSL via the Forward proxy, I'll get a failure such as:
{noformat}
igalic@knock ~/src % svn co
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/
svn: PROPFIND of '/svnroot/gar/!svn/bln/14844': Could not create SSL connection
through proxy server: 502 Tunnel Connection Failed
(https://gar.svn.sourceforge.net)
1 igalic@knock ~/src %
{noformat}
The squid.blog says:
{noformat}
1308609250.117 1004 127.0.0.1 TCP_MISS/200 4664 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609250.642 524 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.167 525 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.689 522 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.231 541 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.756 524 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.285 528 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.814 528 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.345 530 127.0.0.1 TCP_MISS/200 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.416 70 127.0.0.1 ERR_CONNECT_FAIL/502 454 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net text/html -
{noformat}
While the error log says:
{noformat}
20110621.00h25m14s RESPONSE: sent 127.0.0.1 status 502 (Tunnel Connection
Failed) for 'gar.svn.sourceforge.net:443/'
{noformat}
With newer versions of the Subversion server this works out fine, example the
ASF's server:
{noformat}
igalic@knock ~/src % svn co
https://svn.apache.org/repos/asf/trafficserver/plugins/header_filter/
Aheader_filter/example.conf
Aheader_filter/rules.h
Aheader_filter/NOTICE
Aheader_filter/header_filter.cc
Aheader_filter/LICENSE
Aheader_filter/STATUS
Aheader_filter/lulu.h
Aheader_filter/CHANGES
Aheader_filter/Makefile
Aheader_filter/README
Aheader_filter/rules.cc
Checked out revision 1137808.
igalic@knock ~/src %
{noformat}
I wouldn't submit this bug in the first place, if it didn't work with Squid
either. Alas Squid passes with flying colours! Attatched you can find wireshark
captures for the four scenarios:
* Failure with ATS (old subversion server: sf.net)
* Success with Squid (same old subversion server: sf.net)
* Success with ATS (new Subversion server: ASF)
* Success with Squid (same new Subversion server: ASF)
To force subversion through a proxy you need to edit ~/.subversion/servers
{noformat}
[global]
http-proxy-host = localhost
http-proxy-port = 8080
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-847) Forward proxy: Can't create SSL connection to older Subversion Servers.
[
https://issues.apache.org/jira/browse/TS-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Galić updated TS-847:
--
Attachment: 04_pass_squid_asf.cap
03_pass_ats_asf.cap
02_pass_squid_sfnet.cap
01_fail_ats_sfnet.cap
tshark -w $fname.cap -i lo port $port
Forward proxy: Can't create SSL connection to older Subversion Servers.
---
Key: TS-847
URL: https://issues.apache.org/jira/browse/TS-847
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.0, 3.0.0
Reporter: Igor Galić
Attachments: 01_fail_ats_sfnet.cap, 02_pass_squid_sfnet.cap,
03_pass_ats_asf.cap, 04_pass_squid_asf.cap
When trying to access older Subversion (1.6.9, 1.5.1 verified) servers
through SSL via the Forward proxy, I'll get a failure such as:
{noformat}
igalic@knock ~/src % svn co
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/
svn: PROPFIND of '/svnroot/gar/!svn/bln/14844': Could not create SSL
connection through proxy server: 502 Tunnel Connection Failed
(https://gar.svn.sourceforge.net)
1 igalic@knock ~/src %
{noformat}
The squid.blog says:
{noformat}
1308609250.117 1004 127.0.0.1 TCP_MISS/200 4664 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609250.642 524 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.167 525 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.689 522 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.231 541 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.756 524 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.285 528 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.814 528 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.345 530 127.0.0.1 TCP_MISS/200 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.416 70 127.0.0.1 ERR_CONNECT_FAIL/502 454 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net text/html -
{noformat}
While the error log says:
{noformat}
20110621.00h25m14s RESPONSE: sent 127.0.0.1 status 502 (Tunnel Connection
Failed) for 'gar.svn.sourceforge.net:443/'
{noformat}
With newer versions of the Subversion server this works out fine, example the
ASF's server:
{noformat}
igalic@knock ~/src % svn co
https://svn.apache.org/repos/asf/trafficserver/plugins/header_filter/
Aheader_filter/example.conf
Aheader_filter/rules.h
Aheader_filter/NOTICE
Aheader_filter/header_filter.cc
Aheader_filter/LICENSE
Aheader_filter/STATUS
Aheader_filter/lulu.h
Aheader_filter/CHANGES
Aheader_filter/Makefile
Aheader_filter/README
Aheader_filter/rules.cc
Checked out revision 1137808.
igalic@knock ~/src %
{noformat}
I wouldn't submit this bug in the first place, if it didn't work with Squid
either. Alas Squid passes with flying colours! Attatched you can find
wireshark captures for the four scenarios:
* Failure with ATS (old subversion server: sf.net)
* Success with Squid (same old subversion server: sf.net)
* Success with ATS (new Subversion server: ASF)
* Success with Squid (same new Subversion server: ASF)
To force subversion through a proxy you need to edit ~/.subversion/servers
{noformat}
[global]
http-proxy-host = localhost
http-proxy-port = 8080
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-847) Forward proxy: Can't create SSL connection to older Subversion Servers.
[
https://issues.apache.org/jira/browse/TS-847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052282#comment-13052282
]
Leif Hedstrom commented on TS-847:
--
Did a few tracers (it certainly seems a lot more difficult to reproduce this
with tracers on, so perhaps a race / timing issue). First is request that
succeeds:
{code}
+ Proxy's Request +
-- State Machine Id: 173
CONNECT / HTTP/1.1
User-Agent: SVN/1.6.16 (r1073529) neon/0.29.5
Host: gar.svn.sourceforge.net
Client-ip: 127.0.0.1
X-Forwarded-For: 127.0.0.1
Via: http/1.1 loki.ogre.com[C0A8C90E] (ApacheTrafficServer/3.1.0-unstable [uSc
])
[Jun 20 17:44:43.914] Server {139680396424960} DEBUG: (http_trans) Next action
next; HttpTransact::HandleResponse
[Jun 20 17:44:43.914] Server {139680396424960} DEBUG: (http) [173] State
Transition: API_OS_DNS - ORIGIN_SERVER_RAW_OPEN
[Jun 20 17:44:43.914] Server {139680396424960} DEBUG: (http_track) entered
inside do_http_server_open
[Jun 20 17:44:43.914] Server {139680396424960} DEBUG: (http) [173] open
connection to gar.svn.sourceforge.net: 216.34.181.177
[Jun 20 17:44:43.914] Server {139680396424960} DEBUG: (http_seq)
[HttpSM::do_http_server_open] Sending request to server
[Jun 20 17:44:43.914] Server {139680396424960} DEBUG: (http) calling
netProcessor.connect_s
[Jun 20 17:44:43.965] Server {139680396424960} DEBUG: (http) [173]
[HttpSM::main_handler, NET_EVENT_OPEN]
[Jun 20 17:44:43.965] Server {139680396424960} DEBUG: (http) [173]
[HttpSM::state_raw_http_server_open, NET_EVENT_OPEN]
[Jun 20 17:44:43.965] Server {139680396424960} DEBUG: (http_trans)
[HttpTransact::OriginServerRawOpen]
[Jun 20 17:44:43.965] Server {139680396424960} DEBUG: (http_trans) [WUTS code
generation] Hit/Miss: 49, Log: 51, Hier: 50, Status: 200
[Jun 20 17:44:43.965] Server {139680396424960} DEBUG: (http_trans) Adding
Server: ATS/3.1.0-unstable
{code}
and here's a request that failed:
{code}
+ Proxy's Request +
-- State Machine Id: 174
CONNECT / HTTP/1.1
User-Agent: SVN/1.6.16 (r1073529) neon/0.29.5
Host: gar.svn.sourceforge.net
Client-ip: 127.0.0.1
X-Forwarded-For: 127.0.0.1
Via: http/1.1 loki.ogre.com[C0A8C90E] (ApacheTrafficServer/3.1.0-unstable [uSc
])
[Jun 20 17:44:44.388] Server {139680397477632} DEBUG: (http_trans) Next action
next; HttpTransact::HandleResponse
[Jun 20 17:44:44.388] Server {139680397477632} DEBUG: (http) [174] State
Transition: API_OS_DNS - ORIGIN_SERVER_RAW_OPEN
[Jun 20 17:44:44.388] Server {139680397477632} DEBUG: (http_track) entered
inside do_http_server_open
[Jun 20 17:44:44.388] Server {139680397477632} DEBUG: (http) [174] open
connection to gar.svn.sourceforge.net: 216.34.181.177
[Jun 20 17:44:44.388] Server {139680397477632} DEBUG: (http_seq)
[HttpSM::do_http_server_open] Sending request to server
[Jun 20 17:44:44.388] Server {139680397477632} DEBUG: (http) calling
netProcessor.connect_s
[Jun 20 17:44:44.428] Server {139680397477632} DEBUG: (http) [174]
[HttpSM::main_handler, NET_EVENT_OPEN_FAILED]
[Jun 20 17:44:44.428] Server {139680397477632} DEBUG: (http) [174]
[HttpSM::state_raw_http_server_open, NET_EVENT_OPEN_FAILED]
[Jun 20 17:44:44.428] Server {139680397477632} DEBUG: (http_trans)
[HttpTransact::OriginServerRawOpen]
[Jun 20 17:44:44.428] Server {139680397477632} DEBUG: (http_trans) [WUTS code
generation] Hit/Miss: 49, Log: 117, Hier: 50, Status: 805
[Jun 20 17:44:44.428] Server {139680397477632} DEBUG: (http_trans) Adding
Server: ATS/3.1.0-unstable
+ Proxy's Response 2 +
{code}
Forward proxy: Can't create SSL connection to older Subversion Servers.
---
Key: TS-847
URL: https://issues.apache.org/jira/browse/TS-847
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.0, 3.0.0
Reporter: Igor Galić
Attachments: 01_fail_ats_sfnet.cap, 02_pass_squid_sfnet.cap,
03_pass_ats_asf.cap, 04_pass_squid_asf.cap
When trying to access older Subversion (1.6.9, 1.5.1 verified) servers
through SSL via the Forward proxy, I'll get a failure such as:
{noformat}
igalic@knock ~/src % svn co
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/
svn: PROPFIND of '/svnroot/gar/!svn/bln/14844': Could not create SSL
connection through proxy server: 502 Tunnel Connection Failed
(https://gar.svn.sourceforge.net)
1 igalic@knock ~/src %
{noformat}
The squid.blog says:
{noformat}
1308609250.117 1004 127.0.0.1 TCP_MISS/200 4664 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609250.642 524 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.167 525 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.689 522 127.0.0.1 TCP_MISS/200 1095
[jira] [Commented] (TS-833) Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef, ink_freelist_free related
[
https://issues.apache.org/jira/browse/TS-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052302#comment-13052302
]
mohan_zl commented on TS-833:
-
{code}
#0 0x0063f9f5 in get_dns (h=0x18ea3070, id=27816) at DNS.cc:752
752 if (e-once_written_flag)
(gdb) bt
#0 0x0063f9f5 in get_dns (h=0x18ea3070, id=27816) at DNS.cc:752
#1 0x00643e33 in dns_process (handler=0x18ea3070, buf=0x2aaab1292010,
len=159) at DNS.cc:1170
#2 0x00645cfc in DNSHandler::recv_dns (this=0x18ea3070, event=5,
e=0x18e7df50) at DNS.cc:690
#3 0x0064655f in DNSHandler::mainEvent (this=0x18ea3070, event=5,
e=0x18e7df50) at DNS.cc:703
#4 0x004d302f in Continuation::handleEvent (this=0x18ea3070, event=5,
data=0x18e7df50) at I_Continuation.h:146
#5 0x006f9978 in EThread::process_event (this=0x2ae29010,
e=0x18e7df50, calling_code=5) at UnixEThread.cc:140
#6 0x006f9e96 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:262
#7 0x004ff74d in main (argc=3, argv=0x7fff21439ac8) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff214382c0:
rip = 0x63f9f5 in get_dns (DNS.cc:752); saved rip 0x643e33
called by frame at 0x7fff214390a0
source language c++.
Arglist at 0x7fff214382b0, args: h=0x18ea3070, id=27816
Locals at 0x7fff214382b0, Previous frame's sp is 0x7fff214382c0
Saved registers:
rbp at 0x7fff214382b0, rip at 0x7fff214382b8
(gdb) info args
h = (DNSHandler *) 0x18ea3070
id = 27816
(gdb) p h
$1 = (DNSHandler *) 0x18ea3070
(gdb) p h-handler_name
$2 = 0x755f55 DNSHandler::mainEvent
{code}
Crash Report: Continuation::handleEvent, event=2, 0xdeadbeef,
ink_freelist_free related
---
Key: TS-833
URL: https://issues.apache.org/jira/browse/TS-833
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.0
Environment: current trunk, with --enable-debug
Reporter: Zhao Yongming
Labels: freelist
Fix For: 3.1.0
Attachments: TS-833-2.diff, TS-833-3.diff, TS-833.diff
bt #1
{code}
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d2c5c in Continuation::handleEvent (this=0x19581df0,
event=2, data=0x197c4fc0) at I_Continuation.h:146
#1 0x006f5830 in EThread::process_event (this=0x2ae29010,
e=0x197c4fc0, calling_code=2) at UnixEThread.cc:140
#2 0x006f5b72 in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x004ff37d in main (argc=3, argv=0x7fff76c41528) at Main.cc:1958
(gdb) info f
Stack level 0, frame at 0x7fff76c40e40:
rip = 0x4d2c5c in Continuation::handleEvent(int, void*)
(I_Continuation.h:146); saved rip 0x6f5830
called by frame at 0x7fff76c40eb0
source language c++.
Arglist at 0x7fff76c40e30, args: this=0x19581df0, event=2, data=0x197c4fc0
Locals at 0x7fff76c40e30, Previous frame's sp is 0x7fff76c40e40
Saved registers:
rbp at 0x7fff76c40e30, rip at 0x7fff76c40e38
(gdb) x/40x this
0x19581df0: 0x19581901 0x 0xefbeadde 0xefbeadde
0x19581e00: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e10: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e20: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e30: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e40: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e50: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e60: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e70: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
0x19581e80: 0xefbeadde 0xefbeadde 0xefbeadde 0xefbeadde
{code}
bt #2
{code}
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
146 return (this-*handler) (event, data);
(gdb) bt
#0 0x004d637c in Continuation::handleEvent (this=0xc3cc390, event=2,
data=0xc4408a0) at I_Continuation.h:146
#1 0x0070364c in EThread::process_event (this=0x2ae29010,
e=0xc4408a0, calling_code=2) at UnixEThread.cc:140
#2 0x0070398e in EThread::execute (this=0x2ae29010) at
UnixEThread.cc:217
#3 0x00502aac in main (argc=3, argv=0x7fff32ef2f58) at Main.cc:1961
(gdb) p *this
$1 = {force_VFPT_to_top = {_vptr.force_VFPT_to_top = 0x2aaab002f011},
handler = 0xefbeaddeefbeadde, this adjustment -1171307680053154338,
handler_name = 0xefbeaddeefbeadde Address 0xefbeaddeefbeadde out of
bounds, mutex = {m_ptr =
[jira] [Updated] (TS-847) Forward proxy: Can't create SSL connection to older Subversion Servers.
[
https://issues.apache.org/jira/browse/TS-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-847:
-
Attachment: TS-847.diff
Igor, can you test the included patch? That seems to fix this problem for me at
least.
Forward proxy: Can't create SSL connection to older Subversion Servers.
---
Key: TS-847
URL: https://issues.apache.org/jira/browse/TS-847
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.0, 3.0.0
Reporter: Igor Galić
Attachments: 01_fail_ats_sfnet.cap, 02_pass_squid_sfnet.cap,
03_pass_ats_asf.cap, 04_pass_squid_asf.cap, TS-847.diff
When trying to access older Subversion (1.6.9, 1.5.1 verified) servers
through SSL via the Forward proxy, I'll get a failure such as:
{noformat}
igalic@knock ~/src % svn co
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/
svn: PROPFIND of '/svnroot/gar/!svn/bln/14844': Could not create SSL
connection through proxy server: 502 Tunnel Connection Failed
(https://gar.svn.sourceforge.net)
1 igalic@knock ~/src %
{noformat}
The squid.blog says:
{noformat}
1308609250.117 1004 127.0.0.1 TCP_MISS/200 4664 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609250.642 524 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.167 525 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.689 522 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.231 541 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.756 524 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.285 528 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.814 528 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.345 530 127.0.0.1 TCP_MISS/200 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.416 70 127.0.0.1 ERR_CONNECT_FAIL/502 454 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net text/html -
{noformat}
While the error log says:
{noformat}
20110621.00h25m14s RESPONSE: sent 127.0.0.1 status 502 (Tunnel Connection
Failed) for 'gar.svn.sourceforge.net:443/'
{noformat}
With newer versions of the Subversion server this works out fine, example the
ASF's server:
{noformat}
igalic@knock ~/src % svn co
https://svn.apache.org/repos/asf/trafficserver/plugins/header_filter/
Aheader_filter/example.conf
Aheader_filter/rules.h
Aheader_filter/NOTICE
Aheader_filter/header_filter.cc
Aheader_filter/LICENSE
Aheader_filter/STATUS
Aheader_filter/lulu.h
Aheader_filter/CHANGES
Aheader_filter/Makefile
Aheader_filter/README
Aheader_filter/rules.cc
Checked out revision 1137808.
igalic@knock ~/src %
{noformat}
I wouldn't submit this bug in the first place, if it didn't work with Squid
either. Alas Squid passes with flying colours! Attatched you can find
wireshark captures for the four scenarios:
* Failure with ATS (old subversion server: sf.net)
* Success with Squid (same old subversion server: sf.net)
* Success with ATS (new Subversion server: ASF)
* Success with Squid (same new Subversion server: ASF)
To force subversion through a proxy you need to edit ~/.subversion/servers
{noformat}
[global]
http-proxy-host = localhost
http-proxy-port = 8080
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-847) Forward proxy: Can't create SSL connection to older Subversion Servers.
[
https://issues.apache.org/jira/browse/TS-847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-847:
-
Backport to Version: 3.0.1
Fix Version/s: 3.1.0
Forward proxy: Can't create SSL connection to older Subversion Servers.
---
Key: TS-847
URL: https://issues.apache.org/jira/browse/TS-847
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.1.0, 3.0.0
Reporter: Igor Galić
Fix For: 3.1.0
Attachments: 01_fail_ats_sfnet.cap, 02_pass_squid_sfnet.cap,
03_pass_ats_asf.cap, 04_pass_squid_asf.cap, TS-847.diff
When trying to access older Subversion (1.6.9, 1.5.1 verified) servers
through SSL via the Forward proxy, I'll get a failure such as:
{noformat}
igalic@knock ~/src % svn co
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar/
svn: PROPFIND of '/svnroot/gar/!svn/bln/14844': Could not create SSL
connection through proxy server: 502 Tunnel Connection Failed
(https://gar.svn.sourceforge.net)
1 igalic@knock ~/src %
{noformat}
The squid.blog says:
{noformat}
1308609250.117 1004 127.0.0.1 TCP_MISS/200 4664 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609250.642 524 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.167 525 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609251.689 522 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.231 541 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609252.756 524 127.0.0.1 TCP_MISS/200 1031 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.285 528 127.0.0.1 TCP_MISS/200 1095 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609253.814 528 127.0.0.1 TCP_MISS/200 1335 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.345 530 127.0.0.1 TCP_MISS/200 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net - -
1308609254.416 70 127.0.0.1 ERR_CONNECT_FAIL/502 454 CONNECT
gar.svn.sourceforge.net:443/ - DIRECT/gar.svn.sourceforge.net text/html -
{noformat}
While the error log says:
{noformat}
20110621.00h25m14s RESPONSE: sent 127.0.0.1 status 502 (Tunnel Connection
Failed) for 'gar.svn.sourceforge.net:443/'
{noformat}
With newer versions of the Subversion server this works out fine, example the
ASF's server:
{noformat}
igalic@knock ~/src % svn co
https://svn.apache.org/repos/asf/trafficserver/plugins/header_filter/
Aheader_filter/example.conf
Aheader_filter/rules.h
Aheader_filter/NOTICE
Aheader_filter/header_filter.cc
Aheader_filter/LICENSE
Aheader_filter/STATUS
Aheader_filter/lulu.h
Aheader_filter/CHANGES
Aheader_filter/Makefile
Aheader_filter/README
Aheader_filter/rules.cc
Checked out revision 1137808.
igalic@knock ~/src %
{noformat}
I wouldn't submit this bug in the first place, if it didn't work with Squid
either. Alas Squid passes with flying colours! Attatched you can find
wireshark captures for the four scenarios:
* Failure with ATS (old subversion server: sf.net)
* Success with Squid (same old subversion server: sf.net)
* Success with ATS (new Subversion server: ASF)
* Success with Squid (same new Subversion server: ASF)
To force subversion through a proxy you need to edit ~/.subversion/servers
{noformat}
[global]
http-proxy-host = localhost
http-proxy-port = 8080
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-845) invalid setting of proxy.config.cluster.ethernet_interface will prevent traffc_manager from starting
[
https://issues.apache.org/jira/browse/TS-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-845:
-
Attachment: TS-845.patch
set the default cluster interface to system default LOOPBACK virtual network
interface, this is a fast fix for this bug, and we may need to rework the whole
ClusterComunication system initialize when we have someone cleanup the
mgmt/web2(the webui).
invalid setting of proxy.config.cluster.ethernet_interface will prevent
traffc_manager from starting
Key: TS-845
URL: https://issues.apache.org/jira/browse/TS-845
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.1.0, 3.0.0
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Critical
Labels: cluster, network
Fix For: 3.1.0
Attachments: TS-845.patch
when you set an invalid interface in proxy.config.cluster.ethernet_interface,
it will just crash.
{code}
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL:
[LocalManager::initCCom] Unable to find network interface eth5. Exiting...
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL: (last system error 2:
No such file or directory)
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-845) invalid setting of proxy.config.cluster.ethernet_interface will prevent traffc_manager from starting
[
https://issues.apache.org/jira/browse/TS-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052337#comment-13052337
]
Leif Hedstrom commented on TS-845:
--
Seems reasonable to me, assuming clustering still works with the interface set
to lo / lo0 (I have not tested that).
invalid setting of proxy.config.cluster.ethernet_interface will prevent
traffc_manager from starting
Key: TS-845
URL: https://issues.apache.org/jira/browse/TS-845
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.1.0, 3.0.0
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Critical
Labels: cluster, network
Fix For: 3.1.0
Attachments: TS-845.patch
when you set an invalid interface in proxy.config.cluster.ethernet_interface,
it will just crash.
{code}
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL:
[LocalManager::initCCom] Unable to find network interface eth5. Exiting...
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL: (last system error 2:
No such file or directory)
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-845) invalid setting of proxy.config.cluster.ethernet_interface will prevent traffc_manager from starting
[
https://issues.apache.org/jira/browse/TS-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052338#comment-13052338
]
Zhao Yongming commented on TS-845:
--
yeah, it does no effect when you really want to setup the cluster type=1, in
that case you will need to change the interface to a real interface like eth0.
this patch will just make it is safe to remove the whole cluster config block
from records.config if you like, and don't drive the newbie crazy when they
copy the records.config to another system where there is no eth0 but bonding0 :D
invalid setting of proxy.config.cluster.ethernet_interface will prevent
traffc_manager from starting
Key: TS-845
URL: https://issues.apache.org/jira/browse/TS-845
Project: Traffic Server
Issue Type: Bug
Components: Clustering
Affects Versions: 3.1.0, 3.0.0
Reporter: Zhao Yongming
Assignee: Zhao Yongming
Priority: Critical
Labels: cluster, network
Fix For: 3.1.0
Attachments: TS-845.patch
when you set an invalid interface in proxy.config.cluster.ethernet_interface,
it will just crash.
{code}
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL:
[LocalManager::initCCom] Unable to find network interface eth5. Exiting...
[Jun 20 15:31:15.350] Manager {140230882367264} FATAL: (last system error 2:
No such file or directory)
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Jun 20 15:31:15.351] Manager {140230882367264} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
