[jira] [Commented] (TS-3632) libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
[ https://issues.apache.org/jira/browse/TS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14648395#comment-14648395 ] Igor Galić commented on TS-3632: i'd like to point out that this is still failing on 5.3.1: https://launchpadlibrarian.net/211818045/buildlog_ubuntu-precise-amd64.trafficserver_5.3.1-2ah3~precise1_BUILDING.txt.gz either our cherrypick wasn't such a success, or it's a regression, or something else. but it's still/again failing. > libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final > - > > Key: TS-3632 > URL: https://issues.apache.org/jira/browse/TS-3632 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 5.3.0 >Reporter: Igor Galić >Assignee: Jean Baptiste Favre > Fix For: 5.3.1, 6.0.0 > > > When building ATS 5.3.0 on Ubuntu >11.04[1,2] a linking failure occurs > because of the ordering of the libraries: > {code} > libtool: link: c++ -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 > -Wformat -Wformat-security -Werror=format-security -pipe -Wall > -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof > -mcx16 -rdynamic -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z > -Wl,now -o .libs/traffic_manager AddConfigFilesHere.o traffic_manager.o > StatProcessor.o StatType.o StatXML.o ../../mgmt/web2/libweb.a > ../../mgmt/api/.libs/libmgmtapilocal.a > /«PKGBUILDDIR»/lib/ts/.libs/libtsutil.so -lssl -lcrypto -L/usr/lib > ../../mgmt/.libs/libmgmt_lm.a ../../proxy/hdrs/libhdrs.a > ../../lib/records/librecords_lm.a ../../lib/ts/.libs/libtsutil.so > ../../iocore/eventsystem/libinkevent.a ../../proxy/shared/liberror.a > ../../proxy/shared/libdiagsconfig.a -lresolv -ltcl8.5 -lhwloc -lm > ../../lib/wccp/libwccp.a ../../lib/tsconfig/.libs/libtsconfig.so -lcap -lpcre > -lz -lcrypt -lpthread -lrt -ldl /usr/lib/x86_64-linux-gnu/libxml2.so > -Wl,-rpath -Wl,/usr/lib/trafficserver > /usr/bin/ld: ../../lib/wccp/libwccp.a(WccpMsg.o): undefined reference to > symbol 'MD5_Final@@OPENSSL_1.0.0' > /usr/bin/ld: note: 'MD5_Final@@OPENSSL_1.0.0' is defined in DSO > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so so > try adding it to the linker command line > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so: > could not read symbols: Invalid operation > collect2: ld returned 1 exit status > make[3]: *** [traffic_manager] Error 1 > make[3]: Leaving directory `/«PKGBUILDDIR»/cmd/traffic_manager' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/«PKGBUILDDIR»/cmd' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/«PKGBUILDDIR»' > dh_auto_build: make -j1 returned exit code 2 > make: *** [binary-arch] Error 2 > {code} > [1] > https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries > [2] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4794) fix the memory leaks
Bryon Gloden, CISSP® created TS-4794: Summary: fix the memory leaks Key: TS-4794 URL: https://issues.apache.org/jira/browse/TS-4794 Project: Traffic Server Issue Type: Bug Components: DNS, Network Reporter: Bryon Gloden, CISSP® With reference to (WRT) https://github.com/apache/trafficserver/pull/855, on line no. 74 of 'test_P_DNS.cc' there is a memory leak and on line no. 72 of 'test_P_Net.cc' there is memory leak -- both memory leaks are errors. Ping [~zwoop] Found by https://github.com/bryongloden/cppcheck -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2225) Add line/record id to traffic_logcat
[ https://issues.apache.org/jira/browse/TS-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423086#comment-15423086 ] Ask Bjørn Hansen commented on TS-2225: -- Just since I opened the issue: We don't use the binary log anymore for other reasons (the collation stuff being hard to manage primarily), so as far as I'm concerned this is not worth working on. > Add line/record id to traffic_logcat > > > Key: TS-2225 > URL: https://issues.apache.org/jira/browse/TS-2225 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Ask Bjørn Hansen > Fix For: sometime > > > For tailing the binary log it'll be useful with a concept roughly equivalent > to line number in a text file. > traffic_logcat will optionally output this and then have a feature to say > "start following from line/record X". > The record id a numeric increment for the particular log file or the request > ID (if/when that's available). > The immediate objective is for log readers to continue reading from where > they last read if they're restarted. >  -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] Created: (TS-334) Backport of fixes from trunk to 2.0.x branch
Backport of fixes from trunk to 2.0.x branch Key: TS-334 URL: https://issues.apache.org/jira/browse/TS-334 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 2.0.0 Environment: opensuse 11.2 x86_64 Reporter: Marcus Rückert Fix For: 2.0.1 In r938607 bcall fixed TS-322 for trunk. I would propose to backport atleast the char as index subscription chunks to the 2.0.x branch and release that as 2.0.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-334) Backport of fixes from trunk to 2.0.x branch
[ https://issues.apache.org/jira/browse/TS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Rückert updated TS-334: -- Attachment: trafficserver-2.0.0-compile_fixes.patch backport of the changes i needed for building. > Backport of fixes from trunk to 2.0.x branch > > > Key: TS-334 > URL: https://issues.apache.org/jira/browse/TS-334 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 2.0.0 > Environment: opensuse 11.2 x86_64 >Reporter: Marcus Rückert > Fix For: 2.0.1 > > Attachments: trafficserver-2.0.0-compile_fixes.patch > > > In r938607 bcall fixed TS-322 for trunk. > I would propose to backport atleast the char as index subscription chunks to > the 2.0.x branch and release that as 2.0.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-335) make install DESTDIR broken for files in datadir and localstatedir
make install DESTDIR broken for files in datadir and localstatedir -- Key: TS-335 URL: https://issues.apache.org/jira/browse/TS-335 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 2.0.0 Environment: openSUSE 11.2 x86_64 Reporter: Marcus Rückert Fix For: 2.0.1 make install destdir=/usr/src/packages/BUILDROOT/trafficserver-2.0.0-build all the files installed to $datadir and $localstatedir get prefixed with DESTDIR twice. so you end up with /usr/src/packages/BUILDROOT/trafficserver-2.0.0-build/usr/src/packages/BUILDROOT/trafficserver-2.0.0-build/var/trafficserver/TS_version expected would be /usr/src/packages/BUILDROOT/trafficserver-2.0.0-build/var/trafficserver/TS_version -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-415) Adds a Debian to config.layout
Adds a Debian to config.layout Key: TS-415 URL: https://issues.apache.org/jira/browse/TS-415 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 2.1.2 Reporter: Igor Galić This addition is inspired by httpd's -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-415) Adds a Debian to config.layout
[ https://issues.apache.org/jira/browse/TS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-415: -- Attachment: debian-layout.patch > Adds a Debian to config.layout > > > Key: TS-415 > URL: https://issues.apache.org/jira/browse/TS-415 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.2 >Reporter: Igor Galić > Attachments: debian-layout.patch > > > This addition is inspired by httpd's -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-405) SSL Termination not working
[ https://issues.apache.org/jira/browse/TS-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898019#action_12898019 ] Igor Galić commented on TS-405: --- I'm currently using trunk. Before, with 2.1.1 I've been struggling with the same issue. Aside from using trunk, it seems that the sane solution here is to put the server certificate and the server key in the same pem file: i.ga...@pheme /etc/bw/trafficserver % uncomment records.config|grep ssl.server|grep -v NULL CONFIG proxy.config.ssl.server_port INT 443 CONFIG proxy.config.ssl.server.cert.filename STRING multi.brainsware.org.bundle.pem CONFIG proxy.config.ssl.server.cert.path STRING /etc/bw/certs CONFIG proxy.config.ssl.server.private_key.path STRING /etc/bw/certs This, evidently: https://roscm.esotericsystems.at/ works. > SSL Termination not working > --- > > Key: TS-405 > URL: https://issues.apache.org/jira/browse/TS-405 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 2.1.1 > Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 6) > - x86_64 >Reporter: Anirban Roy > Fix For: 2.1.2 > > > Turned on SSL termination with Apache TS-2.1.1 (proxy.config.ssl.enabled) > with other config options left as the default settings. The packages is > shipped with a certificate (server.pm) which is used for SSL session. With > this default setting, the SSL termination does not seem to work. See the > error below - > [anirb...@llf531136 trafficserver]$ https_proxy=localhost:443 wget -d > --no-check-certificate https://login/yahoo.com > Setting --check-certificate (checkcertificate) to 0 > DEBUG output created by Wget 1.10.2 (Red Hat modified) on linux-gnu. > --11:24:41-- https://login/yahoo.com >=> `yahoo.com' > Resolving localhost... 127.0.0.1 > Caching localhost => 127.0.0.1 > Connecting to localhost|127.0.0.1|:443... connected. > Created socket 3. > Releasing 0x00552380 (new refcount 1). > ---request begin--- > CONNECT login:443 HTTP/1.0 > User-Agent: Wget/1.10.2 (Red Hat modified) > ---request end--- > Failed reading proxy response: Connection reset by peer > Closed fd 3 > Retrying. > == > syslog output > == > [anirb...@llf531136 ats-test]$ tail -f /var/log/messages | grep traffic > Jul 27 11:02:22 llf531136 traffic_manager[20264]: {182924636832} ERROR: > (last system error 9: Bad file descriptor) > Jul 27 11:24:18 llf531136 traffic_cop[25036]: --- Cop Starting [Version: > Apache Traffic Server - traffic_cop - 2.1.1-unstable - (build # 62010 on Jul > 20 2010 at 10:17:13)] --- > Jul 27 11:24:18 llf531136 traffic_cop[25036]: traffic_manager not running, > making sure traffic_server is dead > Jul 27 11:24:18 llf531136 traffic_cop[25036]: spawning traffic_manager > Jul 27 11:24:18 llf531136 traffic_manager[25037]: NOTE: --- Manager Starting > --- > Jul 27 11:24:18 llf531136 traffic_manager[25037]: NOTE: Manager Version: > Apache Traffic Server - traffic_manager - 2.1.1-unstable - (build # 62010 on > Jul 20 2010 at 10:17:39) > Jul 27 11:24:18 llf531136 traffic_manager[25037]: {182924636832} NOTE: > updated diags config > Jul 27 11:24:18 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [Rollback::openFile] Open of cache.config failed: Permission denied > Jul 27 11:24:18 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [Rollback::Rollback] Config file is read-only : cache.config > Jul 27 11:24:18 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [ClusterCom::ClusterCom] Node running on OS: 'Linux' Release: > '2.6.9-67.0.22.ELsmp' > Jul 27 11:24:18 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [LocalManager::listenForProxy] Listening on port: 8085 > Jul 27 11:24:18 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [LocalManager::listenForProxy] Listening on port: 443 > Jul 27 11:24:18 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [TrafficManager] Setup complete > Jul 27 11:24:19 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [LocalManager::startProxy] Launching ts process > Jul 27 11:24:19 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [LocalManager::pollMgmtProcessServer] New process connecting fd '10' > Jul 27 11:24:19 llf531136 traffic_manager[25037]: {182924636832} NOTE: > [Alarms::signalAlarm] Server Process born > Jul 27 11:24:20 llf53
[jira] Created: (TS-427) Build ATS with clang
Build ATS with clang Key: TS-427 URL: https://issues.apache.org/jira/browse/TS-427 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 2.1.3 Environment: OS: Any; Clang --version: clang version 1.1 (branches/release_27) Target: x86_64-pc-linux-gnu Thread model: posix Reporter: Igor Galić I've started compiling, and cleaning up traffic-server from trunk with clang, with this config: i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat config.notnice #! /bin/sh # # Created by configure CC="clang"; export CC CXX="clang"; export CXX CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS "./configure" \ "--enable-layout=opt" \ "--with-user=proxy" \ "--with-group=proxy" \ "CC=clang" \ "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ "LDFLAGS=-Wl,--as-needed" \ "CXX=clang" \ "$@" i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % Until I hit errors that seemed to include templates. I'm uploading the current patch for you to sanity-check and review. If it makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Attachment: ats.clang.patch > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.3 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats.clang.patch > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy" \ > "--with-group=proxy" \ > "CC=clang" \ > "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ > "LDFLAGS=-Wl,--as-needed" \ > "CXX=clang" \ > "$@" > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % > Until I hit errors that seemed to include templates. > I'm uploading the current patch for you to sanity-check and review. If it > makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903639#action_12903639 ] Igor Galić commented on TS-427: --- The stuff with templates: make[1]: Entering directory `/home/i.galic/Projects/asf/trafficserver/librecords' clang -DHAVE_CONFIG_H -DREC_BUILD_MGMT2 -I. -I../libinktomi++ -I../librecords -I../iocore/eventsystem -I../iocore/net -I../iocore/cache -I../iocore/aio -I../iocore/utils -I../iocore/cluster -I../iocore/dns -I../iocore/hostdb -I../proxy/mgmt2 -I../proxy/mgmt2/cluster -I../proxy/mgmt2/snmp -I../proxy/mgmt2/web2 -I../proxy/mgmt2/api2/include -I../proxy/mgmt2/utils -I../proxy/http2 -I../proxy/hdrs -I../proxy -I../libinktomi++ -D_LARGEFILE64_SOURCE=1 -D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.5 -DPROCESS_MANAGER -fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -MT librecprocess_a-RecProcess.o -MD -MP -MF .deps/librecprocess_a-RecProcess.Tpo -c -o librecprocess_a-RecProcess.o `test -f 'RecProcess.cc' || echo './'`RecProcess.cc In file included from RecProcess.cc:24: In file included from ../libinktomi++/inktomi++.h:86: In file included from ../libinktomi++/DAllocator.h:44: ../libinktomi++/List.h:245:16: error: use of undeclared identifier 'prev' tail = (C*)prev(e); ^ this-> In file included from RecProcess.cc:26: In file included from ../iocore/eventsystem/P_EventSystem.h:41: In file included from ../iocore/eventsystem/I_EventSystem.h:37: In file included from ../iocore/eventsystem/I_EThread.h:30: ../iocore/eventsystem/I_PriorityEventQueue.h:98:23: note: in instantiation of member function 'Queue::remove' requested here after[e->in_heap].remove(e); ^ In file included from RecProcess.cc:24: In file included from ../libinktomi++/inktomi++.h:86: In file included from ../libinktomi++/DAllocator.h:44: ../libinktomi++/List.h:150:7: note: must qualify identifier to find this declaration in dependent base class C *&prev(C *e) { return *(C**)&L::prev_link(e); } ^ 3 diagnostics generated. make[1]: *** [librecprocess_a-RecProcess.o] Error 1 is explained here: http://www.parashift.com/c++-faq-lite/templates.html#faq-35.19 > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.3 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats.clang.patch > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy" \ > "--with-group=proxy" \ > "CC=clang" \ > "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ > "LDFLAGS=-Wl,--as-needed" \ > "CXX=clang" \ > "$@" > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % > Until I hit errors that seemed to include templates. > I'm uploading the current patch for you to sanity-check and review. If it > makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903678#action_12903678 ] Igor Galić commented on TS-427: --- error: address of register variable requested num_chars channot be a register variable anymore -> http://stackoverflow.com/questions/1256246/address-of-register-variable > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.3 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats.clang.patch > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy" \ > "--with-group=proxy" \ > "CC=clang" \ > "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ > "LDFLAGS=-Wl,--as-needed" \ > "CXX=clang" \ > "$@" > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % > Until I hit errors that seemed to include templates. > I'm uploading the current patch for you to sanity-check and review. If it > makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Attachment: ats.clang.compile.patch This patch gets us far enough to compile ATS with clang. However, there are some things which need attention. In some places there are comments which suggest that my patch will fail with VC++. For one, for the other: Format strings in printf dervates need attention. Or better yet, a wrapper like APR has. > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.3 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats.clang.compile.patch, ats.clang.patch > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy" \ > "--with-group=proxy" \ > "CC=clang" \ > "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ > "LDFLAGS=-Wl,--as-needed" \ > "CXX=clang" \ > "$@" > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % > Until I hit errors that seemed to include templates. > I'm uploading the current patch for you to sanity-check and review. If it > makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Attachment: ats.clang.patch This is the current state. It compiles and runs.. oh well.. almost: CC="/opt/bw/bin/clang"; export CC CXX="/opt/bw/bin/clang++"; export CXX LD="/opt/bw/bin/clang++"; export LD CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS CXXFLAGS="-x c++ -fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS "./configure" \ "--enable-layout=opt" \ "--with-user=proxy" \ "--with-group=proxy" \ "--enable-debug" This will get us through the compile, but when running the regression test, and port 8080 is busy, we will segfault: r...@phoenix:~# /opt/trafficserver/bin/traffic_server -R 1 Layout configuration --prefix = '/opt/trafficserver' --exec_prefix = '/opt/trafficserver' --bindir = '/opt/trafficserver/bin' --sbindir = '/opt/trafficserver/sbin' --sysconfdir = '/etc/opt/trafficserver' --datadir = '/opt/trafficserver/share' --includedir = '/opt/trafficserver/include' --libdir = '/opt/trafficserver/lib' --libexecdir = '/opt/trafficserver/libexec' --localstatedir = '/var/opt/trafficserver' --sharedstatedir = '/opt/trafficserver' --runtimedir = '/var/opt/trafficserver/run' --logdir = '/var/opt/trafficserver/logs' --mandir = '/opt/trafficserver/man' --infodir = '/opt/trafficserver/info' --cachedir = '/var/opt/trafficserver/cache' [TrafficServer] using root directory '/opt/trafficserver' [Aug 28 15:15:29.056] {139700967716640} STATUS: opened /var/opt/trafficserver/logs/diags.log [Aug 28 15:15:29.235] Server {139700967716640} ERROR: Could not bind or listen to port 8080 (error: -1) [Aug 28 15:15:29.237] Server {139700771809040} FATAL: HTTP accept received fatal error: errno = 9 FATAL: UnixUDPNet.cc:295: failed assert `event != NULL` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7f0eaad33711] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7f0eaad33880] NOTE: Traffic Server received Sig 11: Segmentation fault /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7f0eaad328d2] /opt/trafficserver/bin/traffic_server(_ZN19UDPReadContinuationD1Ev+0x50)[0x7f0eaad06530] /opt/trafficserver/bin/traffic_server(_ZN14ClassAllocatorI19UDPReadContinuationE6_protoD2Ev+0x15)[0x7f0eaad0d085] /opt/trafficserver/bin/traffic_server(+0x1d2e02)[0x7f0eaaae1e02] /lib/libpthread.so.0(+0xf8f0)[0x7f0ea9e0a8f0] [0x] Segmentation fault (core dumped) When the port is not busy, it fails a certain test with abort: [SDK_API_INKContDataGet] INKContDataGet : [TestCase1] <> { ok } FATAL: ./P_CacheInternal.h:617: failed assert `!part || this_ethread() != part->mutex->thread_holding` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7f29fdf0a711] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7f29fdf0a880] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7f29fdf098d2] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC8callcontEi+0x8a)[0x7f29fdea43da] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC21openReadStartEarliestEiP5Event+0xe37)[0x7f29fdea1c27] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x78)[0x7f29fdc3bfb8] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0xc67)[0x7f29fde78557] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x78)[0x7f29fdc3bfb8] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC21openReadStartEarliestEiP5Event+0xd27)[0x7f29fdea1b17] /opt/trafficserver/bin/traffic_server(_ZN7CacheVC18openReadFromWriterEiP5Event+0x1840)[0x7f29fde9efb0] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x78)[0x7f29fdc3bfb8] /opt/trafficserver/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD513CacheFragTypePci+0x589)[0x7f29fde9c439] /opt/trafficserver/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP7INK_MD513CacheFragTypePci+0xbc)[0x7f29fdc6131c] /opt/trafficserver/bin/traffic_server(INKCacheRead+0x1a6)[0x7f29fdc594e6] /opt/trafficserver/bin/traffic_server(_Z13cache_handlerPv8INKEventS_+0x1679)[0x7f29fdc6d069] /opt/trafficserver/bin/traffic_server(_ZN15INKContInternal12handle_eventEiPv+0xe5)[0x7f29fdc47bf5] /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x78)[0x7f
[jira] Commented: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903831#action_12903831 ] Igor Galić commented on TS-427: --- I have confirmed the segmentation fault with GCC on trafficserver trunk with --enable-debug, so I guess I can exclude my patchset as suspect, also, this should probably be a separate defect? r...@phoenix:~# /opt/ats-vanilla-gcc/bin/traffic_server -R 1 Layout configuration --prefix = '/opt/ats-vanilla-gcc' --exec_prefix = '/opt/ats-vanilla-gcc' --bindir = '/opt/ats-vanilla-gcc/bin' --sbindir = '/opt/ats-vanilla-gcc/sbin' --sysconfdir = '/etc/opt/ats-vanilla-gcc' --datadir = '/opt/ats-vanilla-gcc/share' --includedir = '/opt/ats-vanilla-gcc/include' --libdir = '/opt/ats-vanilla-gcc/lib' --libexecdir = '/opt/ats-vanilla-gcc/libexec' --localstatedir = '/var/opt/ats-vanilla-gcc' --sharedstatedir = '/opt/ats-vanilla-gcc' --runtimedir = '/var/opt/ats-vanilla-gcc/run' --logdir = '/var/opt/ats-vanilla-gcc/logs' --mandir = '/opt/ats-vanilla-gcc/man' --infodir = '/opt/ats-vanilla-gcc/info' --cachedir = '/var/opt/ats-vanilla-gcc/cache' [TrafficServer] using root directory '/opt/ats-vanilla-gcc' [Aug 28 16:42:57.423] {140617315079968} STATUS: opened /var/opt/ats-vanilla-gcc/logs/diags.log [Aug 28 16:42:57.777] Server {140617315079968} ERROR: Could not bind or listen to port 8080 (error: -1) [Aug 28 16:42:57.779] Server {140617191810832} FATAL: HTTP accept received fatal error: errno = 9 FATAL: UnixUDPNet.cc:295: failed assert `event != NULL` /opt/ats-vanilla-gcc/bin/traffic_server - STACK TRACE: NOTE: Traffic Server received Sig 11: Segmentation fault /opt/ats-vanilla-gcc/bin/traffic_server - STACK TRACE: /opt/ats-vanilla-gcc/bin/traffic_server(ink_fatal_va+0xd4)[0x7fe4055cec18] /opt/ats-vanilla-gcc/bin/traffic_server(ink_fatal+0xc9)[0x7fe4055ced04] /opt/ats-vanilla-gcc/bin/traffic_server(_ink_assert+0xd1)[0x7fe4055cddb1] /opt/ats-vanilla-gcc/bin/traffic_server(_ZN19UDPReadContinuationD1Ev+0x46)[0x7fe4055a4fb0] /opt/ats-vanilla-gcc/bin/traffic_server(_ZN14ClassAllocatorI19UDPReadContinuationE6_protoD1Ev+0x18)[0x7fe4055abe4e] /opt/ats-vanilla-gcc/bin/traffic_server(_ZN14ClassAllocatorI19UDPReadContinuationED1Ev+0x1c)[0x7fe4055ac55a] /opt/ats-vanilla-gcc/bin/traffic_server(+0x1b0082)[0x7fe4053b1082] /lib/libc.so.6(exit+0xe2)[0x7fe402cba262] /lib/libpthread.so.0(+0xf8f0)[0x7fe404dd08f0] /opt/ats-vanilla-gcc/bin/traffic_server(+0x136cb9)[0x[0x7fe405337cb9] ] Segmentation fault (core dumped) Produced with: CC="gcc"; export CC CXX="g++"; export CXX CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS "./configure" \ "--prefix=/opt/ats-vanilla-gcc" \ "--enable-layout=opt" \ "--with-user=proxy" \ "--with-group=proxy" \ "--enable-debug" \ "CC=$CC" \ "CXX=$CXX" \ "CFLAGS=$CFLAGS" \ "CXXFLAGS=$CFLAGS" \ "LDFLAGS=$LDFLAGS" \ "$@" Once the regression test on the clang patchset is done, I'll test for the abort() -- then run the regression test with GCC compiled clang-patchset. > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.3 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats.clang.compile.patch, ats.clang.patch, ats.clang.patch > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy" \ > "--with-group=proxy" \ > "CC=clang" \ > "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ > "LDFLAGS=-Wl,--as-needed" \ > "CXX=clang" \ > "$@" > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % > Until I hit errors that seemed to include templates. > I'm uploading the current patch for you to sanity-check and review. If it > makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903844#action_12903844 ] Igor Galić commented on TS-427: --- Regression tests: r...@phoenix:~# time /opt/ats-vanilla-gcc/bin/traffic_server -R 1 2>&1| grep -w FAIL [SDK_API_INKfopen] mkstemp : [std func] <> { can't create file for writing } [SDK_API_INKPluginDirGet] INKPluginDirGet : [TestCase2] <> { plugin dir(/opt/ats-vanilla-gcc/libexec) is incorrect, expected (libexec/trafficserver) in path } [SDK_API_INKCache] INKCacheRemove : [TestCase1] <> { can't remove cached item } [SDK_API_INKHttpConnectServerIntercept] INKHttpConnect : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectServerIntercept] INKHttpTxnServerIntercept : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpConnect : [TestCase1] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpTxnIntercept : [TestCase1] <> { Unexpected response } [SDK_API_HttpAltInfo] INKHttpAltInfo : [All] <> { Test not executed even once } [SDK_API_HttpTxnTransform] INKHttpTxnUntransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKHttpTxnTransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transformed_resp_cache } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass untransformed_resp_cache } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transform_create } [SDK_API_HttpHookAdd] INKHttpHookAdd : [TestCase1] <> { Hooks not called or request failure. Hook mask = 1 } [SDK_API_HttpHookAdd] INKHttpTxnReenable : [TestCase1] <> { Txn not reenabled properly } real1m52.899s user0m16.830s sys 0m1.290s r...@phoenix:~# r...@phoenix:~# time /opt/ats-clangpatch-gcc/bin/traffic_server -R 1 2>&1| grep -w FAIL [SDK_API_INKfopen] mkstemp : [std func] <> { can't create file for writing } [SDK_API_INKPluginDirGet] INKPluginDirGet : [TestCase2] <> { plugin dir(/opt/ats-clangpatch-gcc/libexec) is incorrect, expected (libexec/trafficserver) in path } [SDK_API_INKHttpConnectServerIntercept] INKHttpConnect : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectServerIntercept] INKHttpTxnServerIntercept : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpConnect : [TestCase1] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpTxnIntercept : [TestCase1] <> { Unexpected response } [SDK_API_HttpAltInfo] INKHttpAltInfo : [All] <> { Test not executed even once } [SDK_API_HttpTxnTransform] INKHttpTxnUntransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKHttpTxnTransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transformed_resp_cache } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transform_create } [SDK_API_HttpHookAdd] INKHttpHookAdd : [TestCase1] <> { Hooks not called or request failure. Hook mask = 1 } [SDK_API_HttpHookAdd] INKHttpTxnReenable : [TestCase1] <> { Txn not reenabled properly } real1m46.821s user0m10.670s sys 0m0.500s r...@phoenix:~# Now, for whatsoever reason, we run into some kind of condition in the ``Regression test(SDK_API_INKCache'', hence the Ctrl+C -- this is clang specific, just like the above abort() -- it doesn't happen with gcc, no matter the patching or the --enable-debug. r...@phoenix:~# time /opt/trafficserver/bin/traffic_server -R 1 2>&1| grep -w FAIL [SDK_API_INKfopen] mkstemp : [std func] <> { can't create file for writing } [SDK_API_INKPluginDirGet] INKPluginDirGet : [TestCase2] <> { plugin dir(/opt/trafficserver/libexec) is incorrect, expected (libexec/trafficserver) in path } [SDK_API_INKHttpConnectServerIntercept] INKHttpConnect : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectServerIntercept] INKHttpTxnServerIntercept : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpConnect : [TestCase1] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpTxnIntercept : [TestCase1] <> { Unexpected response } [SDK_API_HttpAltInfo] INKHttpAltInfo : [All] <> { Test not executed even once } [SDK_API_HttpTxnTransform] INKHttpTxnUntransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKHttpTxnTransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTran
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Attachment: ats_clang_stuck.strace > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.3 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats.clang.compile.patch, ats.clang.patch, > ats.clang.patch, ats_clang_stuck.strace > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy" \ > "--with-group=proxy" \ > "CC=clang" \ > "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ > "LDFLAGS=-Wl,--as-needed" \ > "CXX=clang" \ > "$@" > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % > Until I hit errors that seemed to include templates. > I'm uploading the current patch for you to sanity-check and review. If it > makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-429) rc/trafficserver start/stop quits with bogus status on success.
rc/trafficserver start/stop quits with bogus status on success. --- Key: TS-429 URL: https://issues.apache.org/jira/browse/TS-429 Project: Traffic Server Issue Type: Bug Environment: Debian/Ubuntu Reporter: Igor Galić Priority: Trivial When using trafficserver start or trafficserver stop on Debian/Ubuntu, the script will exit 1, even when successful. The patch is quite trival, see attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-429) rc/trafficserver start/stop quits with bogus status on success.
[ https://issues.apache.org/jira/browse/TS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-429: -- Attachment: ats.rc.debuntu.patch > rc/trafficserver start/stop quits with bogus status on success. > --- > > Key: TS-429 > URL: https://issues.apache.org/jira/browse/TS-429 > Project: Traffic Server > Issue Type: Bug > Environment: Debian/Ubuntu >Reporter: Igor Galić >Priority: Trivial > Attachments: ats.rc.debuntu.patch > > > When using trafficserver start or trafficserver stop on Debian/Ubuntu, the > script will exit 1, even when successful. The patch is quite trival, see > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-429) rc/trafficserver start/stop quits with bogus status on success.
[ https://issues.apache.org/jira/browse/TS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-429: -- Attachment: (was: ats.rc.debuntu.patch) > rc/trafficserver start/stop quits with bogus status on success. > --- > > Key: TS-429 > URL: https://issues.apache.org/jira/browse/TS-429 > Project: Traffic Server > Issue Type: Bug > Environment: Debian/Ubuntu >Reporter: Igor Galić >Priority: Trivial > Attachments: ats.rc.debuntu.patch > > > When using trafficserver start or trafficserver stop on Debian/Ubuntu, the > script will exit 1, even when successful. The patch is quite trival, see > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-429) rc/trafficserver start/stop quits with bogus status on success.
[ https://issues.apache.org/jira/browse/TS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-429: -- Attachment: ats.rc.debuntu.patch Number at the beginning of the line, is the return value of the previous line: i.ga...@pheme ~ % trafficserver start 1 i.ga...@pheme ~ % sudo trafficserver start i.ga...@pheme ~ % trafficserver stop start-stop-daemon: warning: failed to kill 21991: Operation not permitted 1 i.ga...@pheme ~ % sudo trafficserver stop i.ga...@pheme ~ % > rc/trafficserver start/stop quits with bogus status on success. > --- > > Key: TS-429 > URL: https://issues.apache.org/jira/browse/TS-429 > Project: Traffic Server > Issue Type: Bug > Environment: Debian/Ubuntu >Reporter: Igor Galić >Priority: Trivial > Attachments: ats.rc.debuntu.patch > > > When using trafficserver start or trafficserver stop on Debian/Ubuntu, the > script will exit 1, even when successful. The patch is quite trival, see > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-429) rc/trafficserver start/stop quits with bogus status on success.
[ https://issues.apache.org/jira/browse/TS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-429: -- Attachment: ats.rc.debuntu.patch > rc/trafficserver start/stop quits with bogus status on success. > --- > > Key: TS-429 > URL: https://issues.apache.org/jira/browse/TS-429 > Project: Traffic Server > Issue Type: Bug > Environment: Debian/Ubuntu >Reporter: Igor Galić >Priority: Trivial > Attachments: ats.rc.debuntu.patch, ats.rc.debuntu.patch > > > When using trafficserver start or trafficserver stop on Debian/Ubuntu, the > script will exit 1, even when successful. The patch is quite trival, see > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-429) rc/trafficserver start/stop quits with bogus status on success.
[ https://issues.apache.org/jira/browse/TS-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-429: -- Attachment: (was: ats.rc.debuntu.patch) > rc/trafficserver start/stop quits with bogus status on success. > --- > > Key: TS-429 > URL: https://issues.apache.org/jira/browse/TS-429 > Project: Traffic Server > Issue Type: Bug > Environment: Debian/Ubuntu >Reporter: Igor Galić >Priority: Trivial > Attachments: ats.rc.debuntu.patch > > > When using trafficserver start or trafficserver stop on Debian/Ubuntu, the > script will exit 1, even when successful. The patch is quite trival, see > attachment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-415) Adds a Debian to config.layout
[ https://issues.apache.org/jira/browse/TS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904593#action_12904593 ] Igor Galić commented on TS-415: --- This: i.ga...@panic ~/Projects/asf/trafficserver (svn)-[trunk:991146] % svn diff Index: config.layout === --- config.layout (revision 991146) +++ config.layout (working copy) @@ -172,7 +172,7 @@ # Debian layout -prefix: +prefix:/usr exec_prefix: ${prefix}/usr bindir:${exec_prefix}/bin sbindir: ${exec_prefix}/sbin Should fix it. (Or make it work as ``well'' as httpd (I mean apache2) on Debian). > Adds a Debian to config.layout > > > Key: TS-415 > URL: https://issues.apache.org/jira/browse/TS-415 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.2 >Reporter: Igor Galić > Attachments: debian-layout.patch > > > This addition is inspired by httpd's -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906394#action_12906394 ] Igor Galić commented on TS-427: --- Here's a repaste of the above abort(), run through c++filt, so you can actually read it. -- n.b. I'm always compiling against llvm/clang from trunk (in silent that this is clang's issue, not mine ;) FATAL: ./P_CacheInternal.h:617: failed assert `!part || this_ethread() != part->mutex->thread_holding` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7fde1fdc6c11] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7fde1fdc6d80] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7fde1fdc5de2] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x8a)[0x7fde1fd5ffea] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xe50)[0x7fde1fd5d890] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0xc59)[0x7fde1fd34259] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xd40)[0x7fde1fd5d780] /opt/trafficserver/bin/traffic_server(CacheVC::openReadFromWriter(int, Event*)+0x1831)[0x7fde1fd5ac01] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0x589)[0x7fde1fd580a9] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0xbc)[0x7fde1fb210dc] /opt/trafficserver/bin/traffic_server(INKCacheRead+0x1a6)[0x7fde1fb192e6] /opt/trafficserver/bin/traffic_server(cache_handler(void*, INKEvent, void*)+0x1679)[0x7fde1fb2cdf9] /opt/trafficserver/bin/traffic_server(INKContInternal::handle_event(int, void*)+0xe5)[0x7fde1fb07895] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::calluser(int)+0xb6)[0x7fde1fd60146] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x117)[0x7fde1fd69757] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteWriteDone(int, Event*)+0x609)[0x7fde1fd69619] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleWriteLock(int, Event*)+0x16a)[0x7fde1fd50a1a] /opt/trafficserver/bin/traffic_server(CacheVC::do_write_lock_call()+0xae)[0x7fde1fd6c60e] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x5b6)[0x7fde1fd69bf6] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteWriteDone(int, Event*)+0x609)[0x7fde1fd69619] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleWriteLock(int, Event*)+0x16a)[0x7fde1fd50a1a] /opt/trafficserver/bin/traffic_server(CacheVC::do_write_lock_call()+0xae)[0x7fde1fd6c60e] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x5b6)[0x7fde1fd69bf6] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x11c)[0x7fde1fd6007c] /opt/trafficserver/bin/traffic_server(Cache::open_write(Continuation*, INK_MD5*, CacheFragType, int, long, char*, int)+0x594)[0x7fde1fd6b344] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_write(Continuation*, INK_MD5*, CacheFragType, int, int, long, char*, int)+0x124)[0x7fde1fb21214] /opt/trafficserver/bin/traffic_server(INKCacheWrite+0x1c9)[0x7fde1fb19509] /opt/trafficserver/bin/traffic_server(RegressionTest_SDK_API_INKCache(RegressionTest*, int, int*)+0x327)[0x7fde1fb2e147] /opt/trafficserver/bin/traffic_server(+0x437abd)[0x7fde1fdddabd] /opt/trafficserver/bin/traffic_server(RegressionTest::run(char*)+0xa5)[0x7fde1fddd9e5] /opt/trafficserver/bin/traffic_server(RegressionCont::mainEvent(int, Event*)+0xb6)[0x7fde1fb56d16] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(EThread::process_event(Event*, int)+0x171)[0x7fde1fdbc321] /opt/trafficserver/bin/traffic_server(EThread::execute()+0x27f)[0x7fde1fdbc77f] /opt/trafficserver/bin/traffic_server(main+0x194e)[0x7fde1fb5097e] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fde1d444c4d] /opt/trafficserver/bin/traffic_server(+0x12ead9)[0x7fde1fad4ad9] > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-4
[jira] Commented: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906407#action_12906407 ] Igor Galić commented on TS-427: --- If I change the assert() to: ink_debug_assert(!part); The stack trace looks like this: REGRESSION TEST SDK_API_INKCache started [SDK_API_INKCache] INKCacheReady : [TestCase1] <> { ok } [SDK_API_INKCache] INKCacheKeyCreate : [TestCase1] <> { ok } [SDK_API_INKCache] INKCacheKeySetDigest : [TestCase1] <> { ok } [SDK_API_INKContDataGet] INKContDataSet : [TestCase1] <> { ok } [SDK_API_INKContDataGet] INKContDataGet : [TestCase1] <> { ok } [SDK_API_INKActionCancel] INKActionCancel : [TestCase1] <> { ok } [SDK_API_INKContSchedule] INKContSchedule : [TestCase2] <> { ok } FATAL: ./P_CacheInternal.h:618: failed assert `!part` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7fd02e8b5bd1] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7fd02e8b5d40] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7fd02e8b4da2] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x4b)[0x7fd02e84efab] /opt/trafficserver/bin/traffic_server(Cache::open_write(Continuation*, INK_MD5*, CacheFragType, int, long, char*, int)+0x594)[0x7fd02e85a304] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_write(Continuation*, INK_MD5*, CacheFragType, int, int, long, char*, int)+0x124)[0x7fd02e610214] /opt/trafficserver/bin/traffic_server(INKCacheWrite+0x1c9)[0x7fd02e608509] /opt/trafficserver/bin/traffic_server(RegressionTest_SDK_API_INKCache(RegressionTest*, int, int*)+0x327)[0x7fd02e61d147] /opt/trafficserver/bin/traffic_server(+0x437a7d)[0x7fd02e8cca7d] /opt/trafficserver/bin/traffic_server(RegressionTest::run(char*)+0xa5)[0x7fd02e8cc9a5] /opt/trafficserver/bin/traffic_server(RegressionCont::mainEvent(int, Event*)+0xb6)[0x7fd02e645d16] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fd02e5eacc8] /opt/trafficserver/bin/traffic_server(EThread::process_event(Event*, int)+0x171)[0x7fd02e8ab2e1] /opt/trafficserver/bin/traffic_server(EThread::execute()+0x27f)[0x7fd02e8ab73f] /opt/trafficserver/bin/traffic_server(main+0x194e)[0x7fd02e63f97e] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fd02bf33c4d] /opt/trafficserver/bin/traffic_server(+0x12ead9)[0x7fd02e5c3ad9] For ink_debug_assert(this_ethread() != part->mutex->thread_holding); it will look like this: [SDK_API_INKActionCancel] INKActionCancel : [TestCase1] <> { ok } [SDK_API_INKContDataGet] INKContDataSet : [TestCase1] <> { ok } [SDK_API_INKContDataGet] INKContDataGet : [TestCase1] <> { ok } [SDK_API_INKCache] INKCacheWrite : [TestCase1] <> { ok } [SDK_API_INKCache] INKVIOReenable : [TestCase2] <> { ok } [SDK_API_INKCache] INKVIONBytesSet : [TestCase1] <> { ok } [SDK_API_INKCache] INKVConnWrite : [TestCase1] <> { ok } [SDK_API_INKCache] INKVIOBufferGet : [TestCase1] <> { ok } [SDK_API_INKCache] INKVIOContGet : [TestCase1] <> { ok } [SDK_API_INKCache] INKVIOMutexGet : [TestCase1] <> { ok } [SDK_API_INKCache] INKVIOVConnGet : [TestCase1] <> { ok } [SDK_API_INKCache] INKVIOReaderGet : [TestCase1] <> { ok } FATAL: ./P_CacheInternal.h:618: failed assert `this_ethread() != part->mutex->thread_holding` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7f4966520c01] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7f4966520d70] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7f496651fdd2] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x74)[0x7f49664b9fd4] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xe50)[0x7f49664b7890] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7f4966255cc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0xc59)[0x7f496648e259] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7f4966255cc8] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xd40)[0x7f49664b7780] /opt/trafficserver/bin/traffic_server(CacheVC::openReadFromWriter(int, Event*)+0x1831)[0x7f49664b4c01] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7f4966255cc8] /opt/trafficserver/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0x589)[0x7f49664b20a9] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0xbc)[0x7f496627b0dc] /opt/trafficserver/bin/traffic_server(INKCacheRead+0x1a6)[0x7f49662732e6] /opt/trafficserver/bin/traffic_server(cache_handler(void*, INKEvent, void*)+0x1679)[0x7f4966286df9] /opt/traff
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Attachment: ats-trunk.clang-trunk.patch > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.3.0 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats-trunk.clang-trunk.patch, ats.clang.compile.patch, > ats.clang.patch, ats.clang.patch, ats_clang_stuck.strace > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy" \ > "--with-group=proxy" \ > "CC=clang" \ > "CFLAGS=-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2" \ > "LDFLAGS=-Wl,--as-needed" \ > "CXX=clang" \ > "$@" > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % > Until I hit errors that seemed to include templates. > I'm uploading the current patch for you to sanity-check and review. If it > makes sense, I suppose it does a bit of a clean-up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12911004#action_12911004 ] Igor Galić commented on TS-427: --- 8175 fixed in llvm r114259 In testing it, I hit, much, much later, a new assert, in gdb: (gdb) print *d $29 = { = { = {_vptr$force_VFPT_to_top = 0x78276af0}, handler = {ptr = , handler_name = 0x77f7c490 "&Part::aggWriteDone", mutex = {m_ptr = 0x78868380}, link = {> = {next = 0x0}, prev = 0x0}}, path = 0x788cee80 "/var/opt/trafficserver/cache/cache.db", hash_id = 0x788ced10 "/var/opt/trafficserver/cache/cache.db 16384:9727", hash_id_md5 = {b = { 6127868384971469622, 16013774615526535559}}, fd = 24, raw_dir = 0x788d7000 "\r\360\320\361\025", dir = 0x788d9000, header = 0x788d7000, footer = 0x788f3000, segments = 1, buckets = 2482, recover_pos = 8961024, prev_recover_pos = 468992, scan_pos = 10532864, skip = 16384, start = 262144, len = 79683584, data_blocks = 9697, hit_evacuate_window = 0, io = { = { = { = { _vptr$force_VFPT_to_top = 0x78276bb0}, handler = {ptr = , handler_name = 0x77f0 "&AIOCallbackInternal::io_complete", mutex = {m_ptr = 0x78868380}, link = {> = { next = 0x0}, prev = 0x0}}, aiocb = {aio_fildes = 0, aio_buf = 0x703be000, aio_nbytes = 103424, aio_offset = 572416, aio_reqprio = 0, aio_lio_opcode = 2, aio_state = 0, aio__pad = {0}}, action = {_vptr$Action = 0x0, continuation = 0x788d56f0, mutex = {m_ptr = 0x78868380}, cancelled = 0}, thread = 0x, then = 0x0, aio_result = 103424}, first = 0x0, aio_req = 0x7fffec02b600, sleep_time = 0}, agg = { = {head = 0x0}, tail = 0x0}, stat_cache_vcs = { = {head = 0x0}, tail = 0x0}, sync = { = {head = 0x0}, tail = 0x0}, agg_buffer = 0x703be000 "\023\233\022_\204\206\001", agg_todo_size = 0, agg_buf_pos = 0, trigger = 0x0, open_dir = { = { = {_vptr$force_VFPT_to_top = 0x78276b30}, handler = {ptr = , handler_name = 0x77f77d20 "&OpenDir::signal_readers", mutex = {m_ptr = 0x78868380}, link = {> = {next = 0x0}, prev = 0x0}}, delayed_readers = { = {head = 0x0}, tail = 0x0}, bucket = {{head = 0x0} }}, ram_cache = 0x7fffeccca250, evacuate_size = 6, evacuate = 0x788cee20, lookaside = {{head = 0x0} }, doc_evacuator = 0x7c30f00df00d, init_info = 0x0, disk = 0x7fffec02b4a0, cache = 0x788ced70, cache_part = 0x788cea70, last_sync_serial = 4, last_write_serial = 0, sector_size = 512, recover_wrapped = false, dir_sync_waiting = false, dir_sync_in_progress = false, writing_end_marker = false, first_fragment_key = {b = {0, 0}}, first_fragment_offset = 4294993844, first_fragment_data = {m_ptr = 0x0}} (gdb) print *thread $30 = (gdb) print lock $31 = {m = {m_ptr = 0x0}, lock_acquired = false} (gdb) continue Continuing. FATAL: CacheDir.cc:1288: failed assert `lock` /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7f3aac0a1a31] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7f3aac0a1ba0] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7f3aac0a0c02] /opt/trafficserver/bin/traffic_server(RegressionTest_Cache_dir(RegressionTest*, int, int*)+0xde)[0x7f3aac01e61e] /opt/trafficserver/bin/traffic_server(+0x41d88d)[0x7f3aac0b888d] /opt/trafficserver/bin/traffic_server(RegressionTest::run_some()+0x124)[0x7f3aac0b8a34] /opt/trafficserver/bin/traffic_server(RegressionTest::check_status()+0x2f)[0x7f3aac0b8aaf] /opt/trafficserver/bin/traffic_server(RegressionCont::mainEvent(int, Event*)+0xd4)[0x7f3aabe2d9d4] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7f3aabdd6718] /opt/trafficserver/bin/traffic_server(EThread::process_event(Event*, int)+0x171)[0x7f3aac096f91] /opt/trafficserver/bin/traffic_server(EThread::execute()+0x27f)[0x7f3aac0973ef] /opt/trafficserver/bin/traffic_server(main+0x1903)[0x7f3aabe278a3] /lib/libc.so.6(__libc_start_main+0xfe)[0x7f3aa9739d8e] Program received signal SIGABRT, Aborted. 0x755b0ba5 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) > Build ATS with clang > ---- > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.3.0 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats-trunk.clang-trunk.patch, ats.clang.compile.patch, > ats.c
[jira] Issue Comment Edited: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12911004#action_12911004 ] Igor Galić edited comment on TS-427 at 9/18/10 8:24 AM: 8175 fixed in llvm r114259 In testing it, I hit, much, much later, a new assert (gdb) print *d $29 = { = { = {_vptr$force_VFPT_to_top = 0x78276af0}, handler = {ptr = , handler_name = 0x77f7c490 "&Part::aggWriteDone", mutex = {m_ptr = 0x78868380}, link = {> = {next = 0x0}, prev = 0x0}}, path = 0x788cee80 "/var/opt/trafficserver/cache/cache.db", hash_id = 0x788ced10 "/var/opt/trafficserver/cache/cache.db 16384:9727", hash_id_md5 = {b = { 6127868384971469622, 16013774615526535559}}, fd = 24, raw_dir = 0x788d7000 "\r\360\320\361\025", dir = 0x788d9000, header = 0x788d7000, footer = 0x788f3000, segments = 1, buckets = 2482, recover_pos = 8961024, prev_recover_pos = 468992, scan_pos = 10532864, skip = 16384, start = 262144, len = 79683584, data_blocks = 9697, hit_evacuate_window = 0, io = { = { = { = { _vptr$force_VFPT_to_top = 0x78276bb0}, handler = {ptr = , handler_name = 0x77f0 "&AIOCallbackInternal::io_complete", mutex = {m_ptr = 0x78868380}, link = {> = { next = 0x0}, prev = 0x0}}, aiocb = {aio_fildes = 0, aio_buf = 0x703be000, aio_nbytes = 103424, aio_offset = 572416, aio_reqprio = 0, aio_lio_opcode = 2, aio_state = 0, aio__pad = {0}}, action = {_vptr$Action = 0x0, continuation = 0x788d56f0, mutex = {m_ptr = 0x78868380}, cancelled = 0}, thread = 0x, then = 0x0, aio_result = 103424}, first = 0x0, aio_req = 0x7fffec02b600, sleep_time = 0}, agg = { = {head = 0x0}, tail = 0x0}, stat_cache_vcs = { = {head = 0x0}, tail = 0x0}, sync = { = {head = 0x0}, tail = 0x0}, agg_buffer = 0x703be000 "\023\233\022_\204\206\001", agg_todo_size = 0, agg_buf_pos = 0, trigger = 0x0, open_dir = { = { = {_vptr$force_VFPT_to_top = 0x78276b30}, handler = {ptr = , handler_name = 0x77f77d20 "&OpenDir::signal_readers", mutex = {m_ptr = 0x78868380}, link = {> = {next = 0x0}, prev = 0x0}}, delayed_readers = { = {head = 0x0}, tail = 0x0}, bucket = {{head = 0x0} }}, ram_cache = 0x7fffeccca250, evacuate_size = 6, evacuate = 0x788cee20, lookaside = {{head = 0x0} }, doc_evacuator = 0x7c30f00df00d, init_info = 0x0, disk = 0x7fffec02b4a0, cache = 0x788ced70, cache_part = 0x788cea70, last_sync_serial = 4, last_write_serial = 0, sector_size = 512, recover_wrapped = false, dir_sync_waiting = false, dir_sync_in_progress = false, writing_end_marker = false, first_fragment_key = {b = {0, 0}}, first_fragment_offset = 4294993844, first_fragment_data = {m_ptr = 0x0}} (gdb) print *thread $30 = (gdb) print lock $31 = {m = {m_ptr = 0x0}, lock_acquired = false} (gdb) continue Continuing. FATAL: CacheDir.cc:1288: failed assert `lock` /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7f3aac0a1a31] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7f3aac0a1ba0] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7f3aac0a0c02] /opt/trafficserver/bin/traffic_server(RegressionTest_Cache_dir(RegressionTest*, int, int*)+0xde)[0x7f3aac01e61e] /opt/trafficserver/bin/traffic_server(+0x41d88d)[0x7f3aac0b888d] /opt/trafficserver/bin/traffic_server(RegressionTest::run_some()+0x124)[0x7f3aac0b8a34] /opt/trafficserver/bin/traffic_server(RegressionTest::check_status()+0x2f)[0x7f3aac0b8aaf] /opt/trafficserver/bin/traffic_server(RegressionCont::mainEvent(int, Event*)+0xd4)[0x7f3aabe2d9d4] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7f3aabdd6718] /opt/trafficserver/bin/traffic_server(EThread::process_event(Event*, int)+0x171)[0x7f3aac096f91] /opt/trafficserver/bin/traffic_server(EThread::execute()+0x27f)[0x7f3aac0973ef] /opt/trafficserver/bin/traffic_server(main+0x1903)[0x7f3aabe278a3] /lib/libc.so.6(__libc_start_main+0xfe)[0x7f3aa9739d8e] Program received signal SIGABRT, Aborted. 0x755b0ba5 in raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) was (Author: i.galic): 8175 fixed in llvm r114259 In testing it, I hit, much, much later, a new assert, in gdb: (gdb) print *d $29 = { = { = {_vptr$force_VFPT_to_top = 0x78276af0}, handler = {ptr = , handler_name = 0x77f7c490 "&Part::aggWriteDone", mutex = {m_ptr = 0x78868380}, link = {> = {next = 0x0}, prev = 0x0}}, path = 0x788cee80 "/var/opt/trafficserver/cache/cache.db", hash_id = 0x788ced10 "/var/opt/trafficserver/cache/cache.db 16384:9727", hash_id_md5 = {b
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Comment: was deleted (was: I have confirmed the segmentation fault with GCC on trafficserver trunk with --enable-debug, so I guess I can exclude my patchset as suspect, also, this should probably be a separate defect? r...@phoenix:~# /opt/ats-vanilla-gcc/bin/traffic_server -R 1 Layout configuration --prefix = '/opt/ats-vanilla-gcc' --exec_prefix = '/opt/ats-vanilla-gcc' --bindir = '/opt/ats-vanilla-gcc/bin' --sbindir = '/opt/ats-vanilla-gcc/sbin' --sysconfdir = '/etc/opt/ats-vanilla-gcc' --datadir = '/opt/ats-vanilla-gcc/share' --includedir = '/opt/ats-vanilla-gcc/include' --libdir = '/opt/ats-vanilla-gcc/lib' --libexecdir = '/opt/ats-vanilla-gcc/libexec' --localstatedir = '/var/opt/ats-vanilla-gcc' --sharedstatedir = '/opt/ats-vanilla-gcc' --runtimedir = '/var/opt/ats-vanilla-gcc/run' --logdir = '/var/opt/ats-vanilla-gcc/logs' --mandir = '/opt/ats-vanilla-gcc/man' --infodir = '/opt/ats-vanilla-gcc/info' --cachedir = '/var/opt/ats-vanilla-gcc/cache' [TrafficServer] using root directory '/opt/ats-vanilla-gcc' [Aug 28 16:42:57.423] {140617315079968} STATUS: opened /var/opt/ats-vanilla-gcc/logs/diags.log [Aug 28 16:42:57.777] Server {140617315079968} ERROR: Could not bind or listen to port 8080 (error: -1) [Aug 28 16:42:57.779] Server {140617191810832} FATAL: HTTP accept received fatal error: errno = 9 FATAL: UnixUDPNet.cc:295: failed assert `event != NULL` /opt/ats-vanilla-gcc/bin/traffic_server - STACK TRACE: NOTE: Traffic Server received Sig 11: Segmentation fault /opt/ats-vanilla-gcc/bin/traffic_server - STACK TRACE: /opt/ats-vanilla-gcc/bin/traffic_server(ink_fatal_va+0xd4)[0x7fe4055cec18] /opt/ats-vanilla-gcc/bin/traffic_server(ink_fatal+0xc9)[0x7fe4055ced04] /opt/ats-vanilla-gcc/bin/traffic_server(_ink_assert+0xd1)[0x7fe4055cddb1] /opt/ats-vanilla-gcc/bin/traffic_server(_ZN19UDPReadContinuationD1Ev+0x46)[0x7fe4055a4fb0] /opt/ats-vanilla-gcc/bin/traffic_server(_ZN14ClassAllocatorI19UDPReadContinuationE6_protoD1Ev+0x18)[0x7fe4055abe4e] /opt/ats-vanilla-gcc/bin/traffic_server(_ZN14ClassAllocatorI19UDPReadContinuationED1Ev+0x1c)[0x7fe4055ac55a] /opt/ats-vanilla-gcc/bin/traffic_server(+0x1b0082)[0x7fe4053b1082] /lib/libc.so.6(exit+0xe2)[0x7fe402cba262] /lib/libpthread.so.0(+0xf8f0)[0x7fe404dd08f0] /opt/ats-vanilla-gcc/bin/traffic_server(+0x136cb9)[0x[0x7fe405337cb9] ] Segmentation fault (core dumped) Produced with: CC="gcc"; export CC CXX="g++"; export CXX CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS "./configure" \ "--prefix=/opt/ats-vanilla-gcc" \ "--enable-layout=opt" \ "--with-user=proxy" \ "--with-group=proxy" \ "--enable-debug" \ "CC=$CC" \ "CXX=$CXX" \ "CFLAGS=$CFLAGS" \ "CXXFLAGS=$CFLAGS" \ "LDFLAGS=$LDFLAGS" \ "$@" Once the regression test on the clang patchset is done, I'll test for the abort() -- then run the regression test with GCC compiled clang-patchset.) > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.3.0 > Environment: OS: Any; Clang --version: > clang version 1.1 (branches/release_27) > Target: x86_64-pc-linux-gnu > Thread model: posix >Reporter: Igor Galić > Attachments: ats-trunk.clang-trunk.patch, ats.clang.compile.patch, > ats.clang.patch, ats.clang.patch, ats_clang_stuck.strace > > > I've started compiling, and cleaning up traffic-server from trunk with clang, > with this config: > i.ga...@phoenix ~/Projects/asf/trafficserver (svn)-[trunk:989985] % cat > config.notnice > #! /bin/sh > # > # Created by configure > CC="clang"; export CC > CXX="clang"; export CXX > CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS > CXXFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS > LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS > "./configure" \ > "--enable-layout=opt" \ > "--with-user=proxy&qu
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Comment: was deleted (was: Here's a repaste of the above abort(), run through c++filt, so you can actually read it. -- n.b. I'm always compiling against llvm/clang from trunk (in silent that this is clang's issue, not mine ;) FATAL: ./P_CacheInternal.h:617: failed assert `!part || this_ethread() != part->mutex->thread_holding` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7fde1fdc6c11] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7fde1fdc6d80] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7fde1fdc5de2] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x8a)[0x7fde1fd5ffea] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xe50)[0x7fde1fd5d890] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0xc59)[0x7fde1fd34259] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xd40)[0x7fde1fd5d780] /opt/trafficserver/bin/traffic_server(CacheVC::openReadFromWriter(int, Event*)+0x1831)[0x7fde1fd5ac01] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0x589)[0x7fde1fd580a9] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0xbc)[0x7fde1fb210dc] /opt/trafficserver/bin/traffic_server(INKCacheRead+0x1a6)[0x7fde1fb192e6] /opt/trafficserver/bin/traffic_server(cache_handler(void*, INKEvent, void*)+0x1679)[0x7fde1fb2cdf9] /opt/trafficserver/bin/traffic_server(INKContInternal::handle_event(int, void*)+0xe5)[0x7fde1fb07895] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::calluser(int)+0xb6)[0x7fde1fd60146] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x117)[0x7fde1fd69757] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteWriteDone(int, Event*)+0x609)[0x7fde1fd69619] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleWriteLock(int, Event*)+0x16a)[0x7fde1fd50a1a] /opt/trafficserver/bin/traffic_server(CacheVC::do_write_lock_call()+0xae)[0x7fde1fd6c60e] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x5b6)[0x7fde1fd69bf6] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteWriteDone(int, Event*)+0x609)[0x7fde1fd69619] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleWriteLock(int, Event*)+0x16a)[0x7fde1fd50a1a] /opt/trafficserver/bin/traffic_server(CacheVC::do_write_lock_call()+0xae)[0x7fde1fd6c60e] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x5b6)[0x7fde1fd69bf6] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x11c)[0x7fde1fd6007c] /opt/trafficserver/bin/traffic_server(Cache::open_write(Continuation*, INK_MD5*, CacheFragType, int, long, char*, int)+0x594)[0x7fde1fd6b344] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_write(Continuation*, INK_MD5*, CacheFragType, int, int, long, char*, int)+0x124)[0x7fde1fb21214] /opt/trafficserver/bin/traffic_server(INKCacheWrite+0x1c9)[0x7fde1fb19509] /opt/trafficserver/bin/traffic_server(RegressionTest_SDK_API_INKCache(RegressionTest*, int, int*)+0x327)[0x7fde1fb2e147] /opt/trafficserver/bin/traffic_server(+0x437abd)[0x7fde1fdddabd] /opt/trafficserver/bin/traffic_server(RegressionTest::run(char*)+0xa5)[0x7fde1fddd9e5] /opt/trafficserver/bin/traffic_server(RegressionCont::mainEvent(int, Event*)+0xb6)[0x7fde1fb56d16] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(EThread::process_event(Event*, int)+0x171)[0x7fde1fdbc321] /opt/trafficserver/bin/traffic_server(EThread::execute()+0x27f)[0x7fde1fdbc77f] /opt/trafficserver/bin/traffic_server(main+0x194e)[0x7fde1fb5097e] /lib/libc.so.6(__libc_start_main+0xfd)[0x7fde1d444c4d] /opt/trafficserver/bin/traffic_server(+0x12ead9)[0x7fde1fad4ad9]) > Build ATS with clang > > > Key: TS-427 > URL: https://issues.apache.org/jira/browse/TS-427 > Projec
[jira] Issue Comment Edited: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903821#action_12903821 ] Igor Galić edited comment on TS-427 at 9/18/10 8:35 AM: This is the current state. It compiles and runs.. oh well.. almost: CC="/opt/bw/bin/clang"; export CC CXX="/opt/bw/bin/clang++"; export CXX LD="/opt/bw/bin/clang++"; export LD CFLAGS="-fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CFLAGS CXXFLAGS="-x c++ -fPIC -march=core2 -msse4.1 -D_FORTIFY_SOURCE=2"; export CXXFLAGS LDFLAGS="-Wl,--as-needed -Wl,--warn-common"; export LDFLAGS "./configure" \ "--enable-layout=opt" \ "--with-user=proxy" \ "--with-group=proxy" \ "--enable-debug" This will get us through the compile, but when running the regression test, and port 8080 is busy, we will segfault, as this happens with GCC the same, I'll leave that case out and we'll cut to the interesting one: [SDK_API_INKContDataGet] INKContDataGet : [TestCase1] <> { ok } FATAL: ./P_CacheInternal.h:617: failed assert `!part || this_ethread() != part->mutex->thread_holding` /opt/trafficserver/bin/traffic_server - STACK TRACE: /opt/trafficserver/bin/traffic_server(ink_fatal_va+0x111)[0x7fde1fdc6c11] /opt/trafficserver/bin/traffic_server(ink_fatal+0x150)[0x7fde1fdc6d80] /opt/trafficserver/bin/traffic_server(_ink_assert+0x112)[0x7fde1fdc5de2] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x8a)[0x7fde1fd5ffea] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xe50)[0x7fde1fd5d890] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0xc59)[0x7fde1fd34259] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0xd40)[0x7fde1fd5d780] /opt/trafficserver/bin/traffic_server(CacheVC::openReadFromWriter(int, Event*)+0x1831)[0x7fde1fd5ac01] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0x589)[0x7fde1fd580a9] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_read(Continuation*, INK_MD5*, CacheFragType, char*, int)+0xbc)[0x7fde1fb210dc] /opt/trafficserver/bin/traffic_server(INKCacheRead+0x1a6)[0x7fde1fb192e6] /opt/trafficserver/bin/traffic_server(cache_handler(void*, INKEvent, void*)+0x1679)[0x7fde1fb2cdf9] /opt/trafficserver/bin/traffic_server(INKContInternal::handle_event(int, void*)+0xe5)[0x7fde1fb07895] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::calluser(int)+0xb6)[0x7fde1fd60146] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x117)[0x7fde1fd69757] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteWriteDone(int, Event*)+0x609)[0x7fde1fd69619] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleWriteLock(int, Event*)+0x16a)[0x7fde1fd50a1a] /opt/trafficserver/bin/traffic_server(CacheVC::do_write_lock_call()+0xae)[0x7fde1fd6c60e] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x5b6)[0x7fde1fd69bf6] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteWriteDone(int, Event*)+0x609)[0x7fde1fd69619] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::handleWriteLock(int, Event*)+0x16a)[0x7fde1fd50a1a] /opt/trafficserver/bin/traffic_server(CacheVC::do_write_lock_call()+0xae)[0x7fde1fd6c60e] /opt/trafficserver/bin/traffic_server(CacheVC::openWriteMain(int, Event*)+0x5b6)[0x7fde1fd69bf6] /opt/trafficserver/bin/traffic_server(Continuation::handleEvent(int, void*)+0x78)[0x7fde1fafbcc8] /opt/trafficserver/bin/traffic_server(CacheVC::callcont(int)+0x11c)[0x7fde1fd6007c] /opt/trafficserver/bin/traffic_server(Cache::open_write(Continuation*, INK_MD5*, CacheFragType, int, long, char*, int)+0x594)[0x7fde1fd6b344] /opt/trafficserver/bin/traffic_server(CacheProcessor::open_write(Continuation*, INK_MD5*, CacheFragType, int, int, long, char*, int)+0x124)[0x7fde1fb21214] /opt/trafficserver/bin/traffic_server(INKCacheWrite+0x1c9)[0x7fde1fb19509] /opt/trafficserver/bin/traffic_server(RegressionTest_SDK_API_INKCache(RegressionTest*, int, int*)+0x327)[0x7fde1fb2e147] /opt/trafficserver/bin/traffic_server(+0x437abd)[0x7fde1fdddabd] /opt/trafficserver/bin/traffic_server(RegressionTest::run(char*)+0xa5)[0x
[jira] Updated: (TS-427) Build ATS with clang
[ https://issues.apache.org/jira/browse/TS-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-427: -- Comment: was deleted (was: Regression tests: r...@phoenix:~# time /opt/ats-vanilla-gcc/bin/traffic_server -R 1 2>&1| grep -w FAIL [SDK_API_INKfopen] mkstemp : [std func] <> { can't create file for writing } [SDK_API_INKPluginDirGet] INKPluginDirGet : [TestCase2] <> { plugin dir(/opt/ats-vanilla-gcc/libexec) is incorrect, expected (libexec/trafficserver) in path } [SDK_API_INKCache] INKCacheRemove : [TestCase1] <> { can't remove cached item } [SDK_API_INKHttpConnectServerIntercept] INKHttpConnect : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectServerIntercept] INKHttpTxnServerIntercept : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpConnect : [TestCase1] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpTxnIntercept : [TestCase1] <> { Unexpected response } [SDK_API_HttpAltInfo] INKHttpAltInfo : [All] <> { Test not executed even once } [SDK_API_HttpTxnTransform] INKHttpTxnUntransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKHttpTxnTransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transformed_resp_cache } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass untransformed_resp_cache } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transform_create } [SDK_API_HttpHookAdd] INKHttpHookAdd : [TestCase1] <> { Hooks not called or request failure. Hook mask = 1 } [SDK_API_HttpHookAdd] INKHttpTxnReenable : [TestCase1] <> { Txn not reenabled properly } real1m52.899s user0m16.830s sys 0m1.290s r...@phoenix:~# r...@phoenix:~# time /opt/ats-clangpatch-gcc/bin/traffic_server -R 1 2>&1| grep -w FAIL [SDK_API_INKfopen] mkstemp : [std func] <> { can't create file for writing } [SDK_API_INKPluginDirGet] INKPluginDirGet : [TestCase2] <> { plugin dir(/opt/ats-clangpatch-gcc/libexec) is incorrect, expected (libexec/trafficserver) in path } [SDK_API_INKHttpConnectServerIntercept] INKHttpConnect : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectServerIntercept] INKHttpTxnServerIntercept : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpConnect : [TestCase1] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpTxnIntercept : [TestCase1] <> { Unexpected response } [SDK_API_HttpAltInfo] INKHttpAltInfo : [All] <> { Test not executed even once } [SDK_API_HttpTxnTransform] INKHttpTxnUntransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKHttpTxnTransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transformed_resp_cache } [SDK_API_HttpTxnTransform] INKTransformCreate : [TestCase1] <> { did not pass transform_create } [SDK_API_HttpHookAdd] INKHttpHookAdd : [TestCase1] <> { Hooks not called or request failure. Hook mask = 1 } [SDK_API_HttpHookAdd] INKHttpTxnReenable : [TestCase1] <> { Txn not reenabled properly } real1m46.821s user0m10.670s sys 0m0.500s r...@phoenix:~# Now, for whatsoever reason, we run into some kind of condition in the ``Regression test(SDK_API_INKCache'', hence the Ctrl+C -- this is clang specific, just like the above abort() -- it doesn't happen with gcc, no matter the patching or the --enable-debug. r...@phoenix:~# time /opt/trafficserver/bin/traffic_server -R 1 2>&1| grep -w FAIL [SDK_API_INKfopen] mkstemp : [std func] <> { can't create file for writing } [SDK_API_INKPluginDirGet] INKPluginDirGet : [TestCase2] <> { plugin dir(/opt/trafficserver/libexec) is incorrect, expected (libexec/trafficserver) in path } [SDK_API_INKHttpConnectServerIntercept] INKHttpConnect : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectServerIntercept] INKHttpTxnServerIntercept : [TestCase2] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpConnect : [TestCase1] <> { Unexpected response } [SDK_API_INKHttpConnectIntercept] INKHttpTxnIntercept : [TestCase1] <> { Unexpected response } [SDK_API_HttpAltInfo] INKHttpAltInfo : [All] <> { Test not executed even once } [SDK_API_HttpTxnTransform] INKHttpTxnUntransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKHttpTxnTransformedResponseCache : [TestCase1] <> { Value's Mismatch } [SDK_API_HttpTxnTransform] INKTransformCreat
[jira] Commented: (TS-452) Some environment variables (configure) are ATS_ instead of TS_, these should be consistent
[ https://issues.apache.org/jira/browse/TS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915773#action_12915773 ] Igor Galić commented on TS-452: --- With my Vanilla_iceCReam_PonY_ being vetoed, I'll +1 TS_ > Some environment variables (configure) are ATS_ instead of TS_, these should > be consistent > -- > > Key: TS-452 > URL: https://issues.apache.org/jira/browse/TS-452 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Affects Versions: 2.1.3 >Reporter: John Plevyak >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 2.1.4 > > Attachments: TS-452.diff > > > Some environment variables (configure) are ATS_ instead of TS_, these should > be consistent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-583) Build fails if --disable-webui is added
Build fails if --disable-webui is added --- Key: TS-583 URL: https://issues.apache.org/jira/browse/TS-583 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 2.1.5, 2.1.4 Environment: My current environment is: Linux panic 2.6.32-5-amd64 #1 SMP Sat Oct 30 14:18:21 UTC 2010 x86_64 GNU/Linux with: gcc-4.4.real (Debian 4.4.5-8) 4.4.5 But I've also experienced it failing with Clang etc.. Reporter: Igor Galić Even though --disable-webui is default, adding it to the ./configure line seems to trigger something that should be #ifdef-0-ed out. Here's how to repro: {noformat} i.ga...@panic ~/Projects/asf/trafficserver (svn)-[trunk:1042718] % svn co https:// i.ga...@panic ~/Projects/asf/trafficserver (svn)-[trunk:1042718] % autoreconf -i --force i.ga...@panic ~/Projects/asf/trafficserver (svn)-[trunk:1042718] % ./configure --enable-layout=opt --prefix=/opt/bw --with-pic --with-user=www --with-group=www --disable-webui i.ga...@panic ~/Projects/asf/trafficserver (svn)-[trunk:1042718] % make invalid-offsetof -rdynamic -o traffic_manager traffic_manager-Error.o traffic_manager-AddConfigFilesHere.o traffic_manager-Alarms.o traffic_manager-AutoConf.o traffic_manager-BaseManager.o traffic_manager-BaseRecords.o traffic_manager-FileManager.o traffic_manager-LMRecords.o traffic_manager-LocalManager.o traffic_manager-Main.o traffic_manager-MgmtDBM.o traffic_manager-MultiFile.o traffic_manager-RecordsConfig.o traffic_manager-Rollback.o traffic_manager-StatAggregation.o traffic_manager-WebPluginList.o cluster/libcluster.a preparse/libpreparse.a stats/libstats.a web2/libweb.a cli/libcli_lm.a api2/libmgmtapilocal.a utils/libutils_lm.a ../../proxy/hdrs/libhdrs.a ../../lib/records/libreclocal.a ../../proxy/mgmt2/tools/libinksysapi.a ../../proxy/mgmt2/tools/libinkconfigapi.a ../../iocore/utils/libinkutils.a ../../lib/ts/libts.a /usr/lib/libexpat.so -lpcre -lssl -lcrypto /usr/lib/libsqlite3.so -ltcl8.4 -ldl -lnsl -lresolv -lpthread -lrt -lcap -lz cluster/libcluster.a(ClusterCom.o): In function `ClusterCom::handleMultiCastFilePacket(char*, char*)': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/cluster/ClusterCom.cc:1219: undefined reference to `WebHttpTreeRebuildJsTree()' web2/libweb.a(WebOverview.o): In function `overviewPage::generateTable(WebHttpContext*)': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebOverview.cc:1033: undefined reference to `WebHttpGetLink_Xmalloc(char const*)' web2/libweb.a(WebOverview.o): In function `overviewPage::generateAlarmsSummary(WebHttpContext*)': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebOverview.cc:943: undefined reference to `WebHttpGetLink_Xmalloc(char const*)' web2/libweb.a(WebHttp.o): In function `WebHttpHandleConnection(WebHttpConInfo*)': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttp.cc:4215: undefined reference to `WebHttpTreeReturnRefresh(char*)' web2/libweb.a(WebHttp.o): In function `handle_submit_otw_upgrade': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttp.cc:3653: undefined reference to `WebHttpGetLink_Xmalloc(char const*)' web2/libweb.a(WebHttp.o): In function `handle_submit_update': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttp.cc:2887: undefined reference to `WebHttpGetLink_Xmalloc(char const*)' /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttp.cc:2994: undefined reference to `WebHttpTreeRebuildJsTree()' web2/libweb.a(WebHttp.o): In function `handle_submit_snapshot_to_floppy': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttp.cc:2492: undefined reference to `WebHttpGetLink_Xmalloc(char const*)' web2/libweb.a(WebHttp.o): In function `WebHttpInit()': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttp.cc:4150: undefined reference to `WebHttpTreeInit()' web2/libweb.a(WebHttpRender.o): In function `handle_tab_object': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttpRender.cc:803: undefined reference to `WebHttpRenderTabs(textBuffer*, int)' web2/libweb.a(WebHttpRender.o): In function `handle_host_redirect_url': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttpRender.cc:2546: undefined reference to `WebHttpGetLink_Xmalloc(char const*)' web2/libweb.a(WebHttpRender.o): In function `handle_html_tab_object': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttpRender.cc:825: undefined reference to `WebHttpRenderHtmlTabs(textBuffer*, char*, int)' web2/libweb.a(WebHttpRender.o): In function `handle_link_query': /home/i.galic/Projects/asf/trafficserver/proxy/mgmt2/web2/WebHttpRender.cc:1993: undefined reference to `WebHttpGetLinkQuery_Xmalloc(char*)' web2/libweb.a(W
[jira] Assigned: (TS-538) All InkAPIs are now TSAPIs
[ https://issues.apache.org/jira/browse/TS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-538: - Assignee: Igor Galić > All InkAPIs are now TSAPIs > -- > > Key: TS-538 > URL: https://issues.apache.org/jira/browse/TS-538 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić >Priority: Critical > Fix For: 3.0 > > Attachments: ink-2-ts.sh > > > Almost all INK* APIs, as exposed in ts/ts.h, are now prefixed with a TS > instead. There are two exceptions, for two deprecated APIs the name change > does not apply >INKStat* >INKCoupledStat* > These two sets of APIs and enums (etc.) stay with the INK* prefix, since they > are deprecated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-612) ATS does not allow password protected certificates
ATS does not allow password protected certificates -- Key: TS-612 URL: https://issues.apache.org/jira/browse/TS-612 Project: Traffic Server Issue Type: Improvement Components: SSL Affects Versions: 2.1.4 Environment: Any Reporter: Igor Galić Fix For: 2.1.6 Create a (self-signed) certificate with a password that is non-empty. {cat server.key server.crt > server.pem} and configure it as {CONFIG proxy.config.ssl.server.cert.filename STRING server.pem} The result will be: {noformat} Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: --- Server Starting --- Jan 3 10:50:16 proveedores traffic_server[2579]: NOTE: Server Version: Apache Traffic Server - traffic_server - 2.0.1 - (build # 113112 on Dec 31 2010 at 12:58:34) Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} STATUS: opened var/log/trafficserver/diags.log Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: updated diags config Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache clustering disabled Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: no cache disks specified in etc/trafficserver/storage.config: cache disabled Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: cache clustering disabled Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} WARNING: unable to open cache disk(s): Cache Disabled Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL ERROR: Cannot use server private key file. Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL::0:error:0906406D:PEM routines:PEM_def_callback:problems getting password:pem_lib.c:105: Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL::0:error:0906A068:PEM routines:PEM_do_header:bad password read:pem_lib.c:406: Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL::0:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669: Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} ERROR: SSL ERROR: Can't initialize the SSL library, disabling SSL termination!. Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: logging initialized[7], logging_mode = 3 Jan 3 10:50:16 proveedores traffic_server[2579]: {1080362352} NOTE: traffic server running {noformat} A first -- ugly -- shot would be to at least have a password field in the configuration. In the end something taking the input of an external program or from a file would be more desirable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-617) document proxy.config.plugin.extensions_dir
document proxy.config.plugin.extensions_dir --- Key: TS-617 URL: https://issues.apache.org/jira/browse/TS-617 Project: Traffic Server Issue Type: Improvement Components: Configuration Environment: any Reporter: Igor Galić Assignee: Igor Galić Fix For: 2.1.6 Document {{extensions.config}} -- allows a plugin to expose its symbols as "globals", thereby allowing it to expose it to others as API Add an empty default config file, with coments depicting example usage. Similar to plugin.config, {{extensions.config}} lists one plugin per line, with an additional boolean flag regarding how to open the .so file. {noformat} # Example someplugin.so true {noformat} Would pass {{true}} as {{argv[1]}} to {{someplugin.so}}'s {{plugin_init()}}. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-513) sqlite3 should be detected in any visible place by default (not just /usr)
[ https://issues.apache.org/jira/browse/TS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980368#action_12980368 ] Igor Galić commented on TS-513: --- This patch is confusing, because the first part patches iocore/cache/CacheRead.cc for no apparent reason (related to the issue at hand). Furthermore, http://www.gnu.org/software/autoconf/manual/html_node/Libraries.html#Libraries Recommends AC_SEARCH_LIB Does anyone know if any of these Macros will add the -Rpath to platforms which need it? > sqlite3 should be detected in any visible place by default (not just /usr) > -- > > Key: TS-513 > URL: https://issues.apache.org/jira/browse/TS-513 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 2.1.4 >Reporter: John Plevyak > Fix For: 2.1.6 > > Attachments: sqlite3.patch > > > sqlite3 should be detected in any place available from CFLAGS -IXXX -LXXX just > like all the other libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-641) WebUI: Kill it with fire.
WebUI: Kill it with fire. - Key: TS-641 URL: https://issues.apache.org/jira/browse/TS-641 Project: Traffic Server Issue Type: Improvement Components: WebUI Reporter: Igor Galić Assignee: Igor Galić Fix For: 2.1.6 Get rid of proxy/mgmt/html2 Get rid of all code in proxy/mgmt/web2 that is not used Merge used code into proxy/mgmt/utils/WebMgmtUtils.* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-641) WebUI: Kill it with fire.
[ https://issues.apache.org/jira/browse/TS-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982090#action_12982090 ] Igor Galić commented on TS-641: --- r1059308 is a first safe-point. Removed configure and tune subdirectories from html2. Removed admin_access.config, rendered WebUI yet more dysfunctional. > WebUI: Kill it with fire. > - > > Key: TS-641 > URL: https://issues.apache.org/jira/browse/TS-641 > Project: Traffic Server > Issue Type: Improvement > Components: WebUI >Reporter: Igor Galić >Assignee: Igor Galić > Fix For: 2.1.6 > > Original Estimate: 0.23h > Remaining Estimate: 0.23h > > Get rid of proxy/mgmt/html2 > Get rid of all code in proxy/mgmt/web2 that is not used > Merge used code into proxy/mgmt/utils/WebMgmtUtils.* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-665) remove HTTP_ASSERT, which is just an alias for ink_release_assert
remove HTTP_ASSERT, which is just an alias for ink_release_assert - Key: TS-665 URL: https://issues.apache.org/jira/browse/TS-665 Project: Traffic Server Issue Type: Improvement Reporter: Igor Galić Priority: Trivial #define HTTP_ASSERT(_e) ink_release_assert(_e) Should be removed and ink_release_assert() called directly -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (TS-665) remove HTTP_ASSERT, which is just an alias for ink_release_assert
[ https://issues.apache.org/jira/browse/TS-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-665: - Assignee: Igor Galić > remove HTTP_ASSERT, which is just an alias for ink_release_assert > - > > Key: TS-665 > URL: https://issues.apache.org/jira/browse/TS-665 > Project: Traffic Server > Issue Type: Improvement >Reporter: Igor Galić >Assignee: Igor Galić >Priority: Trivial > > #define HTTP_ASSERT(_e) ink_release_assert(_e) > Should be removed and ink_release_assert() called directly -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TS-665) remove HTTP_ASSERT, which is just an alias for ink_release_assert
[ https://issues.apache.org/jira/browse/TS-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-665. --- Resolution: Fixed Fix Version/s: 2.1.6 r1068147 > remove HTTP_ASSERT, which is just an alias for ink_release_assert > - > > Key: TS-665 > URL: https://issues.apache.org/jira/browse/TS-665 > Project: Traffic Server > Issue Type: Improvement >Reporter: Igor Galić >Assignee: Igor Galić >Priority: Trivial > Fix For: 2.1.6 > > > #define HTTP_ASSERT(_e) ink_release_assert(_e) > Should be removed and ink_release_assert() called directly -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TS-665) remove HTTP_ASSERT, which is just an alias for ink_release_assert
[ https://issues.apache.org/jira/browse/TS-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić closed TS-665. - > remove HTTP_ASSERT, which is just an alias for ink_release_assert > - > > Key: TS-665 > URL: https://issues.apache.org/jira/browse/TS-665 > Project: Traffic Server > Issue Type: Improvement >Reporter: Igor Galić >Assignee: Igor Galić >Priority: Trivial > Fix For: 2.1.6 > > > #define HTTP_ASSERT(_e) ink_release_assert(_e) > Should be removed and ink_release_assert() called directly -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TS-672) cleanup Win32 references
cleanup Win32 references Key: TS-672 URL: https://issues.apache.org/jira/browse/TS-672 Project: Traffic Server Issue Type: Improvement Reporter: Igor Galić See: http://www.mail-archive.com/dev@trafficserver.apache.org/msg02413.html -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TS-694) "Alternate Languages" needs to be translated too.
[ https://issues.apache.org/jira/browse/TS-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004149#comment-13004149 ] Igor Galić commented on TS-694: --- My suggestion: leave the "alternative languages" in the document This leaves it up to the translator to translate it. If there are "none" we should generate a link that says "none", linking to a document (in the wiki?) on how to contribute to our documentation/translations. (The URI to that document should be held in vars.txt, rather than hard coded in view.pm) > "Alternate Languages" needs to be translated too. > - > > Key: TS-694 > URL: https://issues.apache.org/jira/browse/TS-694 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Affects Versions: 2.1.7 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll >Priority: Minor > Fix For: 2.1.7 > > > The "Alternate Languages" links are auto-generated rather than being embedded > in the source content files. This creates the problem that the phrase > "Alternate Languages" can't be translated too. The template should be changed > to have pull the phrase from a variable and default to "Alternate Languages". > This way it's always there, but translated files can override it in order to > translate it. It would have to be done for every translated file, but that's > no worse than the previous system which required it for every file, > translated or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TS-701) Remove mgmt/cli/script_configs.sh
Remove mgmt/cli/script_configs.sh - Key: TS-701 URL: https://issues.apache.org/jira/browse/TS-701 Project: Traffic Server Issue Type: Task Components: Cleanup Reporter: Igor Galić Priority: Trivial mgmt/cli/script_configs.sh is not used or useful, it should be removed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TS-709) proxy.config.output.logfile is not configurable
proxy.config.output.logfile is not configurable --- Key: TS-709 URL: https://issues.apache.org/jira/browse/TS-709 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Igor Galić Priority: Minor The code suggests that proxy.config.output.logfile can be set to stdout, stderr, syslog, diagslog or an arbitrary file (if relative, then relative to $logdir). Setting it however, has no effect, the debug output always goes to stderr. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-633) SSL Termination reverse_mapping
[ https://issues.apache.org/jira/browse/TS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008979#comment-13008979 ] Carlos Aguado Sánchez commented on TS-633: -- Running into the same reverse_map issue, I tried with v2.1.7 and the problem persists. The FQDN is properly translated but not the scheme. > SSL Termination reverse_mapping > --- > > Key: TS-633 > URL: https://issues.apache.org/jira/browse/TS-633 > Project: Traffic Server > Issue Type: Bug > Components: Remap API, SSL >Affects Versions: 2.1.0 >Reporter: Andreas Hartke > Fix For: 2.1.8 > > > We configure reverse_proxy with SSL Termination and have problems with > respones from the origin server containing http-adresses. If the origin > server sends reponses with addresses the reverse_mapped adresses from > trafficserver contain http instead of https. > Here our configuration: > map https://asp2.geomagic.de/path/ http://origin_server:8080/path/ > reverse_map http://origin_server:8080/path/ https://asp2.geomagic.de/path/ > redirect_temporary https://asp2.geomagic.de/path > https://asp2.geomagic.de/path/ > The redirection from https to https works fine but a redirect_temporary from > a http-adress to a https-address maps to a http-address instead of a > https-address. > redirect_temporary http://asp2.geomagic.de/gasline > https://asp2.geomagic.de/gasline/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-633) SSL Termination reverse_mapping
[ https://issues.apache.org/jira/browse/TS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Aguado Sánchez updated TS-633: - Attachment: UrlRewrite.cc.patch This patch fixes the issue with reverse_map and different URL schemes. > SSL Termination reverse_mapping > --- > > Key: TS-633 > URL: https://issues.apache.org/jira/browse/TS-633 > Project: Traffic Server > Issue Type: Bug > Components: Remap API, SSL >Affects Versions: 2.1.0 >Reporter: Andreas Hartke > Fix For: 2.1.8 > > Attachments: UrlRewrite.cc.patch > > > We configure reverse_proxy with SSL Termination and have problems with > respones from the origin server containing http-adresses. If the origin > server sends reponses with addresses the reverse_mapped adresses from > trafficserver contain http instead of https. > Here our configuration: > map https://asp2.geomagic.de/path/ http://origin_server:8080/path/ > reverse_map http://origin_server:8080/path/ https://asp2.geomagic.de/path/ > redirect_temporary https://asp2.geomagic.de/path > https://asp2.geomagic.de/path/ > The redirection from https to https works fine but a redirect_temporary from > a http-adress to a https-address maps to a http-address instead of a > https-address. > redirect_temporary http://asp2.geomagic.de/gasline > https://asp2.geomagic.de/gasline/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-633) SSL Termination reverse_mapping
[ https://issues.apache.org/jira/browse/TS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009353#comment-13009353 ] Carlos Aguado Sánchez edited comment on TS-633 at 3/21/11 8:26 PM: --- Problem found: attached is the patch that fixes the issue with reverse_map and different URL schemes. was (Author: caguado): This patch fixes the issue with reverse_map and different URL schemes. > SSL Termination reverse_mapping > --- > > Key: TS-633 > URL: https://issues.apache.org/jira/browse/TS-633 > Project: Traffic Server > Issue Type: Bug > Components: Remap API, SSL >Affects Versions: 2.1.0 >Reporter: Andreas Hartke > Fix For: 2.1.8 > > Attachments: UrlRewrite.cc.patch > > > We configure reverse_proxy with SSL Termination and have problems with > respones from the origin server containing http-adresses. If the origin > server sends reponses with addresses the reverse_mapped adresses from > trafficserver contain http instead of https. > Here our configuration: > map https://asp2.geomagic.de/path/ http://origin_server:8080/path/ > reverse_map http://origin_server:8080/path/ https://asp2.geomagic.de/path/ > redirect_temporary https://asp2.geomagic.de/path > https://asp2.geomagic.de/path/ > The redirection from https to https works fine but a redirect_temporary from > a http-adress to a https-address maps to a http-address instead of a > https-address. > redirect_temporary http://asp2.geomagic.de/gasline > https://asp2.geomagic.de/gasline/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-718) can not reuse SSL connections on RHEL5/CentOS5
[ https://issues.apache.org/jira/browse/TS-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-718: -- Description: when with apache httpd default mod_ssl: {noformat} [root@ts1 httpd]# echo | openssl s_client -reconnect -connect localhost:443 2>&1 CONNECTED(0003) depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com verify return:1 --- Certificate chain 0 s:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com i:/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com --- Server certificate -BEGIN CERTIFICATE- MIIDSzCCArSgAwIBAgICUWcwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MSEwHwYDVQQDDBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG 9w0BCQEWHXJvb3RAdHMxLnRlc3QuY256LmFsaW1hbWEuY29tMB4XDTExMDMyNDEw Mjk1MVoXDTEyMDMyMzEwMjk1MVowgcExCzAJBgNVBAYTAi0tMRIwEAYDVQQIDAlT b21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQKDBBTb21lT3JnYW5p emF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxVbml0MSEwHwYDVQQD DBh0czEudGVzdC5jbnouYWxpbWFtYS5jb20xLDAqBgkqhkiG9w0BCQEWHXJvb3RA dHMxLnRlc3QuY256LmFsaW1hbWEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDg0xr6MMfTUooenmxTyXiaSiHMfrkbGGhjgE0slP1iWfBf62Qal1daSSb8 hSSFCZI78RWAp/bcadHGPo43xDWBmohLyTnlWksKKcbSJ9atdijC2L2CJNXiWgKC cu+2jOTLAw0YJVOufuJmm8QaqmHl4y3UGE626VDN8lPGBCrQcwIDAQABo1AwTjAd BgNVHQ4EFgQUIAfaVLkaRWgWp+zxPtp0bWfbbsgwHwYDVR0jBBgwFoAUIAfaVLka RWgWp+zxPtp0bWfbbsgwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQA1 qYMZB0MuCQz2yCAx25C3+UtoZuxdmQxekmOPjtRAm2CRccW7r0ne57BcVU79Qk2s 6KTU4fO7lJ1tz49ZkX5zts5WuqsWDSb4cfyDb3ybubcZwUu+eSkqVkx/7GAuVgcl weoLXdgpQ779T45SovOR212BXQpYI0piMDNIB9p0mA== -END CERTIFICATE- subject=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com issuer=/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=ts1.test.cnz.alimama.com/emailAddress=r...@ts1.test.cnz.alimama.com --- No client certificate CA names sent --- SSL handshake has read 1418 bytes and written 319 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B Session-ID-ctx: Master-Key: 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA Key-Arg : None Krb5 Principal: None Start Time: 1300962675 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- drop connection and then reconnect CONNECTED(0003) --- Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B Session-ID-ctx: Master-Key: 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA Key-Arg : None Krb5 Principal: None Compression: 1 (zlib compression) Start Time: 1300962675 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- drop connection and then reconnect CONNECTED(0003) --- Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA783FAB8B Session-ID-ctx: Master-Key: 42808C5CDF016480F1BC7FF6F764A4886886E430F8E23400D82A9E6A6DE377A30369541E52BA06E1DC878F18DAFC2ECA Key-Arg : None Krb5 Principal: None Compression: 1 (zlib compression) Start Time: 1300962675 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) --- drop connection and then reconnect CONNECTED(0003) --- Reused, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 Cipher: DHE-RSA-AES256-SHA Session-ID: 8A72957E09AF60AD3807C1D06CE3F9BD88914886B7F1F646B03E8BDA7
[jira] [Resolved] (TS-558) proxy.config.log.config_file and logs.config is eliminated
[ https://issues.apache.org/jira/browse/TS-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-558. --- Resolution: Fixed Assignee: Igor Galić r1085204. > proxy.config.log.config_file and logs.config is eliminated > --- > > Key: TS-558 > URL: https://issues.apache.org/jira/browse/TS-558 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > The config option proxy.config.log.config_file is eliminated, and the entire > config file, logs.config, is removed as well. Instead, people should use the > XML custom log format, which is already documented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-538) All InkAPIs are now TSAPIs
[ https://issues.apache.org/jira/browse/TS-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011023#comment-13011023 ] Igor Galić commented on TS-538: --- In the current revision of the documentation this is the case. We should however check if my renaming wasn't too zealous. > All InkAPIs are now TSAPIs > -- > > Key: TS-538 > URL: https://issues.apache.org/jira/browse/TS-538 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić >Priority: Critical > Fix For: 3.0 > > Attachments: ink-2-ts.sh > > > Almost all INK* APIs, as exposed in ts/ts.h, are now prefixed with a TS > instead. There are two exceptions, for two deprecated APIs the name change > does not apply >INKStat* >INKCoupledStat* > These two sets of APIs and enums (etc.) stay with the INK* prefix, since they > are deprecated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-487) Remove SNMP from Docs
[ https://issues.apache.org/jira/browse/TS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-487. --- Resolution: Fixed There are no references to SNMP in the current revision of the documentation. > Remove SNMP from Docs > - > > Key: TS-487 > URL: https://issues.apache.org/jira/browse/TS-487 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > Since we don't support SNMP inside the TS core, we should remove all docs > related to this feature. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-553) Remove proxy.config.system.memalign_heap from docs
[ https://issues.apache.org/jira/browse/TS-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-553. --- Resolution: Fixed There are no references to proxy.config.system.* in the current revision of the documentation. > Remove proxy.config.system.memalign_heap from docs > -- > > Key: TS-553 > URL: https://issues.apache.org/jira/browse/TS-553 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > This feature / option is no longer available: > proxy.config.system.memalign_heap. Please remove all mentions of it from docs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-546) Eliminate proxy.config.http.streaming_connect_attempts_timeout
[ https://issues.apache.org/jira/browse/TS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-546. --- Resolution: Fixed There are no references to proxy.config.http.streaming in the current revision of the documentation. > Eliminate proxy.config.http.streaming_connect_attempts_timeout > -- > > Key: TS-546 > URL: https://issues.apache.org/jira/browse/TS-546 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > This option is gone, and should be removed from Admin Guide. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-547) Remove proxy.config.resource.target_maxmem_mb from admin guide
[ https://issues.apache.org/jira/browse/TS-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-547. --- Resolution: Fixed There are no references to proxy.config.resource.* in the current revision of the documentation. > Remove proxy.config.resource.target_maxmem_mb from admin guide > -- > > Key: TS-547 > URL: https://issues.apache.org/jira/browse/TS-547 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > This option does nothing, and should be removed from docs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-557) Rename all log2 configs / stats etc. to just log
[ https://issues.apache.org/jira/browse/TS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-557. --- Resolution: Fixed r1038726 > Rename all log2 configs / stats etc. to just log > > > Key: TS-557 > URL: https://issues.apache.org/jira/browse/TS-557 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > All "log2" configurations (and stats) are renamed to "log", e.g. > proxy.config.log2.logging_enabled > is now called > proxy.config.log.logging_enabled -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-585) Remove incomplete RAF component from docs
[ https://issues.apache.org/jira/browse/TS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-585. --- Resolution: Fixed r1085213. > Remove incomplete RAF component from docs > - > > Key: TS-585 > URL: https://issues.apache.org/jira/browse/TS-585 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > The RAF (Remote Access Framework), which we never built or supported (because > several files are missing) is now completely removed. All remaining docs > related to the RAF feature (configs named *.raf.* etc.) should be removed. > The only thing that RAF used to support was listing congested hosts via > traffic_line -q, which never worked in Apache TS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-585) Remove incomplete RAF component from docs
[ https://issues.apache.org/jira/browse/TS-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-585: - Assignee: Igor Galić > Remove incomplete RAF component from docs > - > > Key: TS-585 > URL: https://issues.apache.org/jira/browse/TS-585 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > The RAF (Remote Access Framework), which we never built or supported (because > several files are missing) is now completely removed. All remaining docs > related to the RAF feature (configs named *.raf.* etc.) should be removed. > The only thing that RAF used to support was listing congested hosts via > traffic_line -q, which never worked in Apache TS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-557) Rename all log2 configs / stats etc. to just log
[ https://issues.apache.org/jira/browse/TS-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-557: - Assignee: Igor Galić > Rename all log2 configs / stats etc. to just log > > > Key: TS-557 > URL: https://issues.apache.org/jira/browse/TS-557 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > All "log2" configurations (and stats) are renamed to "log", e.g. > proxy.config.log2.logging_enabled > is now called > proxy.config.log.logging_enabled -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-575) Docs: Rename TCP_DEFER_ACCEPT option and change default
[ https://issues.apache.org/jira/browse/TS-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-575. --- Resolution: Fixed Assignee: Igor Galić r1085215. > Docs: Rename TCP_DEFER_ACCEPT option and change default > --- > > Key: TS-575 > URL: https://issues.apache.org/jira/browse/TS-575 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > We have changed the name of proxy.config.net.tcp_accept_defer_timeout to be > just > proxy.config.net.defer_accept > On linux, this gets a default of 45 seconds now (it was disabled before). On > other platforms supporting similar features, the setting could become an > on-off feature (e.g. 0 or 1), on those platforms the default is now "1". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-602) Traffic Net is removed
[ https://issues.apache.org/jira/browse/TS-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-602. --- Resolution: Fixed The current documentation has no reference to proxy.config.traffic* > Traffic Net is removed > -- > > Key: TS-602 > URL: https://issues.apache.org/jira/browse/TS-602 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > There was some feature named "traffic net", which the Apache TS code does not > support. I've removed this, which also eliminates the following > records.config settings. Please update any documentation that refers to these > options (and the Traffic net feature), we should just remove all such docs. > proxy.config.traffic_net.traffic_net_mode > proxy.config.traffic_net.traffic_net_frequency > proxy.config.traffic_net.traffic_net_uid > proxy.config.traffic_net.traffic_net_lid > proxy.config.traffic_net.traffic_net_server > proxy.config.traffic_net.traffic_net_port > proxy.config.traffic_net.traffic_net_path > proxy.config.traffic_net.traffic_net_encryption -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-606) Remove proxy.config.net.max_poll_delay configs from docs
[ https://issues.apache.org/jira/browse/TS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-606. --- Resolution: Fixed The current revision of the documentation contains no reference to proxy.config.net.m* > Remove proxy.config.net.max_poll_delay configs from docs > - > > Key: TS-606 > URL: https://issues.apache.org/jira/browse/TS-606 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom > Fix For: 3.0 > > > This configuration is gone, no longer used or needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-477) New DNS configuration for resolv.conf
[ https://issues.apache.org/jira/browse/TS-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-477: - Assignee: Igor Galić > New DNS configuration for resolv.conf > - > > Key: TS-477 > URL: https://issues.apache.org/jira/browse/TS-477 > Project: Traffic Server > Issue Type: New Feature > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > There is a new configuration option, so specify which "resolv.conf" file to > use for finding resolvers. The default is > CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf > The format of this file must be the same as the standard resolv.conf file, > but this option allows an administrator to manage the set of resolvers in an > external config file, without affecting how the rest of the operating system > uses DNS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-477) New DNS configuration for resolv.conf
[ https://issues.apache.org/jira/browse/TS-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-477. --- Resolution: Fixed r1085225. > New DNS configuration for resolv.conf > - > > Key: TS-477 > URL: https://issues.apache.org/jira/browse/TS-477 > Project: Traffic Server > Issue Type: New Feature > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > There is a new configuration option, so specify which "resolv.conf" file to > use for finding resolvers. The default is > CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf > The format of this file must be the same as the standard resolv.conf file, > but this option allows an administrator to manage the set of resolvers in an > external config file, without affecting how the rest of the operating system > uses DNS. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-730) [gsoc2011] SSL needs CipherSuite control in negotiation
[ https://issues.apache.org/jira/browse/TS-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-730: -- Summary: [gsoc2011] SSL needs CipherSuite control in negotiation (was: SSL needs CipherSuite control in negotiation ) > [gsoc2011] SSL needs CipherSuite control in negotiation > > > Key: TS-730 > URL: https://issues.apache.org/jira/browse/TS-730 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Affects Versions: 2.1.7 > Environment: ATS trunk + SSL >Reporter: Zhao Yongming > Labels: ssl > > when TS does negotiation, the CipherSuite is not configurable, for this time > being, ciphers short than 128bits it not consider a good protect for secure > connection. we should give CipherSuite more control. for example we can > specify those preferred ciphers we want to use, as Apache httpd. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-462) [GSoc2011] Support TLS Server Name Indication (SNI) negotiation
[ https://issues.apache.org/jira/browse/TS-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-462: -- Description: We should support TLS Server Name Indication (SNI). This would allow for well behaved TLS clients to negotiate the certificate, without requiring a new IP for every site / certificate used. (was: We should support SSL Server Name Indication. This would allow for well behaved TLS clients to negotiate the certificate, without requiring a new IP for every site / certificate used.) Labels: gsoc ssl (was: ) Summary: [GSoc2011] Support TLS Server Name Indication (SNI) negotiation (was: Support SSL / TLS Server Name Indication negotiation) > [GSoc2011] Support TLS Server Name Indication (SNI) negotiation > --- > > Key: TS-462 > URL: https://issues.apache.org/jira/browse/TS-462 > Project: Traffic Server > Issue Type: New Feature > Components: SSL >Reporter: Leif Hedstrom >Priority: Minor > Labels: gsoc, ssl > Fix For: 3.1 > > > We should support TLS Server Name Indication (SNI). This would allow for well > behaved TLS clients to negotiate the certificate, without requiring a new IP > for every site / certificate used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-207) [Gsoc2011] FreeBSD: Add raw disk support for the cache
[ https://issues.apache.org/jira/browse/TS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-207: -- Labels: gsoc2011 (was: ) Summary: [Gsoc2011] FreeBSD: Add raw disk support for the cache (was: FreeBSD: Add raw disk support for the cache) > [Gsoc2011] FreeBSD: Add raw disk support for the cache > -- > > Key: TS-207 > URL: https://issues.apache.org/jira/browse/TS-207 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 2.1.0 > Environment: FreeBSD >Reporter: George Paul >Assignee: Dan Mercer > Labels: gsoc2011 > Fix For: 3.1 > > > Currently only a file cache is supported on FreeBSD. Raw Disk support should > be added before 2.1 release. > -George -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-607) Remove proxy.config.dns.splitdns.def_domain from docs
[ https://issues.apache.org/jira/browse/TS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić reassigned TS-607: - Assignee: Igor Galić > Remove proxy.config.dns.splitdns.def_domain from docs > - > > Key: TS-607 > URL: https://issues.apache.org/jira/browse/TS-607 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > As of TS-597, this configuration option no longer has a purpose, so please > remove from docs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-607) Remove proxy.config.dns.splitdns.def_domain from docs
[ https://issues.apache.org/jira/browse/TS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-607. --- Resolution: Fixed r1088262. > Remove proxy.config.dns.splitdns.def_domain from docs > - > > Key: TS-607 > URL: https://issues.apache.org/jira/browse/TS-607 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom >Assignee: Igor Galić > Fix For: 3.0 > > > As of TS-597, this configuration option no longer has a purpose, so please > remove from docs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-669) [GSoC2011] ATS does not support SSL in IPv6
[ https://issues.apache.org/jira/browse/TS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-669: -- Labels: gsoc2011 ipv6 ssl (was: ) Summary: [GSoC2011] ATS does not support SSL in IPv6 (was: ATS does not support SSL in IPv6) > [GSoC2011] ATS does not support SSL in IPv6 > --- > > Key: TS-669 > URL: https://issues.apache.org/jira/browse/TS-669 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: vijaya bhaskar mamidi > Labels: gsoc2011, ipv6, ssl > Fix For: 3.1 > > > proxy.config.http.server_other_ports is used to support IPv6 but this only > work for http ports and not secure ports. We should support IPv6 for secure > ports as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-523) [GSoC2011] Allow the use of multiple SSL ports
[ https://issues.apache.org/jira/browse/TS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-523: -- Environment: (was: Any?) Labels: gsoc2011 ssl (was: ) Summary: [GSoC2011] Allow the use of multiple SSL ports (was: Allow the use of multiple SSL ports) > [GSoC2011] Allow the use of multiple SSL ports > -- > > Key: TS-523 > URL: https://issues.apache.org/jira/browse/TS-523 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, SSL >Affects Versions: 2.1.3 >Reporter: Marcus Clyne >Priority: Minor > Labels: gsoc2011, ssl > Fix For: 3.1 > > > Currently proxy.config.ssl.server_port allows only one SSL port to be > specified, and it appears that it is not possible to specify multiple ports > for SSL like proxy.config.http.server_other_ports. > It would make sense to have a single directive as a string for all SSL ports, > rather than have two config options like HTTP ports (a separate ticket has > been posted for that - see https://issues.apache.org/jira/browse/TS-524). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-747) [GSoC2011] Add config option to disable SSL compression
[GSoC2011] Add config option to disable SSL compression --- Key: TS-747 URL: https://issues.apache.org/jira/browse/TS-747 Project: Traffic Server Issue Type: Improvement Components: Configuration, SSL Reporter: Igor Galić Priority: Minor A configuration Option should be added to allow the administrator to disable SSL compression CONFIG proxy.config.ssl.compression INT 1 To maintain compatibility it should default to '1' (on) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-755) Should traffic_manager really start a new session?
Should traffic_manager really start a new session? -- Key: TS-755 URL: https://issues.apache.org/jira/browse/TS-755 Project: Traffic Server Issue Type: Bug Environment: Linux (Ubuntu, Fedora, all environments with upstart) Reporter: Igor Galić Fix For: 3.0 Unlike Solaris' SMF, which uses contract(4)s to track processes and their children, upstart simply uses sessions. When starting traffic_cop, this creates a new session, however, traffic_manager does the same. Through the new setsid(), upstart looses track of these children. When trying to stop, it only stops traffic_cop, leaving the rest of the system intact, albeit unsupervised. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-755) Should traffic_manager really start a new session?
[ https://issues.apache.org/jira/browse/TS-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-755: -- Attachment: setsid.patch > Should traffic_manager really start a new session? > -- > > Key: TS-755 > URL: https://issues.apache.org/jira/browse/TS-755 > Project: Traffic Server > Issue Type: Bug > Environment: Linux (Ubuntu, Fedora, all environments with upstart) >Reporter: Igor Galić > Fix For: 3.0 > > Attachments: setsid.patch > > > Unlike Solaris' SMF, which uses contract(4)s to track processes and their > children, upstart simply uses sessions. > When starting traffic_cop, this creates a new session, however, > traffic_manager does the same. > Through the new setsid(), upstart looses track of these children. > When trying to stop, it only stops traffic_cop, leaving the rest of the > system intact, albeit unsupervised. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-768) [GSoc2011] content compression plugin (gzip plugin)
[GSoc2011] content compression plugin (gzip plugin) --- Key: TS-768 URL: https://issues.apache.org/jira/browse/TS-768 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Igor Galić Traffic Server needs a plugin which will allow administrators (of reverse proxies, chiefly) to configure a single point at which content compression happens, thereby reducing the pressure on the back-ends even more Gzipped content SHOULD be cachable. Furthermore it MUST conform to RFC 2616, as well as the upcoming httpbis: see e.g.: http://tools.ietf.org/id/draft-ietf-httpbis-p3-payload-14.txt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-775) Disable cluster autodiscovery via multicast when clustering is disabled (as is by default)
Disable cluster autodiscovery via multicast when clustering is disabled (as is by default) -- Key: TS-775 URL: https://issues.apache.org/jira/browse/TS-775 Project: Traffic Server Issue Type: Bug Components: Clustering Reporter: Igor Galić By default clustering is disabled, however when a freshly installed instance starts up, it tries to discover potential clustering partners via multicast none the less. This is evident with Ubuntu when "ufw" is active, which blocks multicast by default: {noformat} May 12 23:11:46 pheme kernel: [549586.656109] [UFW BLOCK] IN=eth1 OUT= MAC=01:00:5e:00:00:01:fe:54:00:24:07:4d:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 May 12 23:11:46 pheme kernel: [549586.656131] [UFW BLOCK] IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:21:ef:35:90:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 {noformat} When clustering is disabled, as it is by default, we should *not* try to do any kind of discovery either. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-775) Disable cluster autodiscovery via multicast when clustering is disabled (as is by default)
[ https://issues.apache.org/jira/browse/TS-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-775: -- Fix Version/s: 2.1.9 > Disable cluster autodiscovery via multicast when clustering is disabled (as > is by default) > -- > > Key: TS-775 > URL: https://issues.apache.org/jira/browse/TS-775 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: Igor Galić > Fix For: 2.1.9 > > > By default clustering is disabled, however when a freshly installed instance > starts up, it tries to discover potential clustering partners via multicast > none the less. This is evident with Ubuntu when "ufw" is active, which blocks > multicast by default: > {noformat} > May 12 23:11:46 pheme kernel: [549586.656109] [UFW BLOCK] IN=eth1 OUT= > MAC=01:00:5e:00:00:01:fe:54:00:24:07:4d:08:00 SRC=0.0.0.0 DST=224.0.0.1 > LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 > May 12 23:11:46 pheme kernel: [549586.656131] [UFW BLOCK] IN=eth0 OUT= > MAC=01:00:5e:00:00:01:00:24:21:ef:35:90:08:00 SRC=0.0.0.0 DST=224.0.0.1 > LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2 > {noformat} > When clustering is disabled, as it is by default, we should *not* try to do > any kind of discovery either. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-785) Building outside of the tree does not work
Building outside of the tree does not work -- Key: TS-785 URL: https://issues.apache.org/jira/browse/TS-785 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Igor Galić Fix For: 2.1.9 {noformat} igalic@bawnb976 ~/Projects/asf/ats-build % ../trafficserver/configure --prefix=/opt/dev ... igalic@bawnb976 ~/Projects/asf/ats-build % make Making all in proxy/api/ts make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/proxy/api/ts' Making all in iocore make[1]: Entering directory `/home/igalic/Projects/asf/ats-build/iocore' Making all in eventsystem make[2]: Entering directory `/home/igalic/Projects/asf/ats-build/iocore/eventsystem' g++ -DHAVE_CONFIG_H -I. -I../../../trafficserver/iocore/eventsystem -I../../lib/ts -I../../../trafficserver/lib/records -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.4 -mtune=native -march=native -Wall -O3 -march=i586 -g -pipe -Werror -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -MT EventSystem.o -MD -MP -MF .deps/EventSystem.Tpo -c -o EventSystem.o ../../../trafficserver/iocore/eventsystem/EventSystem.cc In file included from ../../../trafficserver/iocore/eventsystem/EventSystem.cc:31:0: ../../../trafficserver/iocore/eventsystem/P_EventSystem.h:39:19: fatal error: libts.h: No such file or directory compilation terminated. make[2]: *** [EventSystem.o] Error 1 make[2]: Leaving directory `/home/igalic/Projects/asf/ats-build/iocore/eventsystem' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/igalic/Projects/asf/ats-build/iocore' make: *** [all-recursive] Error 1 2 igalic@bawnb976 ~/Projects/asf/ats-build % {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-799) Have AdminClient.pm created from .in file
Have AdminClient.pm created from .in file - Key: TS-799 URL: https://issues.apache.org/jira/browse/TS-799 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1 Reporter: Igor Galić Priority: Trivial AdminClient.pm should be created from an .in file. @sockets_def = should be extended with @localstatedir@ on top. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-815) Checks for yacc and flex ae non-fatal if WCCP is enabled
[ https://issues.apache.org/jira/browse/TS-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042799#comment-13042799 ] Igor Galić commented on TS-815: --- I think we really need to discuss sooner or later if it doesn't make sense for a *release* tar-ball at least to have the .yy already pre-processed to C (of course the .yy should still be in the tar ball release). For now, I'll commit this to trunk - thanks Arno > Checks for yacc and flex ae non-fatal if WCCP is enabled > > > Key: TS-815 > URL: https://issues.apache.org/jira/browse/TS-815 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 3.1.0, 3.0.0 >Reporter: Arno Toell >Priority: Minor > Attachments: flexbison-fatal.patch > > > When enabling WCCP (`_--enable-wccp_'), bison and flex is required to build > ATS. There do exist checks for both in autoconf, but they are non-fatal. That > is, _./configure_ succeeds even if none of the required programs are found. > I attached a patch which makes both checks fatal, i.e. they make configure > fail if flex and/or bison is not found. Oh, and by the way autotools really > suck. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-815) Checks for yacc and flex ae non-fatal if WCCP is enabled
[ https://issues.apache.org/jira/browse/TS-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić resolved TS-815. --- Resolution: Fixed Fix Version/s: 3.1.0 Assignee: Igor Galić r1130582 > Checks for yacc and flex ae non-fatal if WCCP is enabled > > > Key: TS-815 > URL: https://issues.apache.org/jira/browse/TS-815 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Affects Versions: 3.1.0, 3.0.0 >Reporter: Arno Toell >Assignee: Igor Galić >Priority: Minor > Fix For: 3.1.0 > > Attachments: flexbison-fatal.patch > > > When enabling WCCP (`_--enable-wccp_'), bison and flex is required to build > ATS. There do exist checks for both in autoconf, but they are non-fatal. That > is, _./configure_ succeeds even if none of the required programs are found. > I attached a patch which makes both checks fatal, i.e. they make configure > fail if flex and/or bison is not found. Oh, and by the way autotools really > suck. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-823) Build fails with --enable-standalone-iocore
Build fails with --enable-standalone-iocore --- Key: TS-823 URL: https://issues.apache.org/jira/browse/TS-823 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 2.1.8, 3.1.0 Reporter: Igor Galić Fix For: 3.1.0 When enabling ./configuring the build with --enable-standalone-iocore the build fails with: {noformat} igalic@bawnb976 ~/Projects/asf/trafficserver/iocore/dns (svn)-[trunk:1132769] % make g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils -I../../iocore/dns -I../../lib/records -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux -I/usr/include/tcl8.4 -march=native -mtune=native -march=i586 -g -pipe -Wall -Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof -MT DNS.o -MD -MP -MF .deps/DNS.Tpo -c -o DNS.o DNS.cc DNS.cc: In member function 'virtual int DNSProcessor::start(int)': DNS.cc:132:7: error: 'SplitDNSConfig' has not been declared DNS.cc:134:5: error: 'SplitDNSConfig' has not been declared DNS.cc: In member function 'void DNSEntry::init(const char*, int, int, Continuation*, DNSHandler*, int)': DNS.cc:261:19: error: 'INK_NOWARN' was not declared in this scope make: *** [DNS.o] Error 1 {noformat} This is due to missing dependencies in Makefile.am: Even though we include "P_DNS.h", which includes "libts.h", which in turn includes "ink_config.h" the compiler doesn't seem to be able to resolve "SPLIT_DNS". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-823) Build fails with --enable-standalone-iocore
[ https://issues.apache.org/jira/browse/TS-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-823: -- Backport to Version: (was: 3.0.0) > Build fails with --enable-standalone-iocore > --- > > Key: TS-823 > URL: https://issues.apache.org/jira/browse/TS-823 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 3.1.0, 2.1.8 >Reporter: Igor Galić > Fix For: 3.1.0 > > > When enabling ./configuring the build with --enable-standalone-iocore the > build fails with: > {noformat} > igalic@bawnb976 ~/Projects/asf/trafficserver/iocore/dns (svn)-[trunk:1132769] > % make > g++ -DHAVE_CONFIG_H -I. -I../../lib/ts -I../../iocore/eventsystem > -I../../iocore/net -I../../iocore/aio -I../../iocore/hostdb > -I../../iocore/cache -I../../iocore/cluster -I../../iocore/utils > -I../../iocore/dns -I../../lib/records -D_LARGEFILE64_SOURCE=1 > -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_REENTRANT -Dlinux > -I/usr/include/tcl8.4 -march=native -mtune=native -march=i586 -g -pipe -Wall > -Werror -O3 -feliminate-unused-debug-symbols -fno-strict-aliasing > -Wno-invalid-offsetof -MT DNS.o -MD -MP -MF .deps/DNS.Tpo -c -o DNS.o DNS.cc > DNS.cc: In member function 'virtual int DNSProcessor::start(int)': > DNS.cc:132:7: error: 'SplitDNSConfig' has not been declared > DNS.cc:134:5: error: 'SplitDNSConfig' has not been declared > DNS.cc: In member function 'void DNSEntry::init(const char*, int, int, > Continuation*, DNSHandler*, int)': > DNS.cc:261:19: error: 'INK_NOWARN' was not declared in this scope > make: *** [DNS.o] Error 1 > {noformat} > This is due to missing dependencies in Makefile.am: Even though we include > "P_DNS.h", which includes "libts.h", which in turn includes "ink_config.h" > the compiler doesn't seem to be able to resolve "SPLIT_DNS". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-820) Restore log buffers to previous defaults
[ https://issues.apache.org/jira/browse/TS-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045494#comment-13045494 ] Igor Galić commented on TS-820: --- There's no documentation, no records.config and no test case for that option. What does the value mean? > Restore log buffers to previous defaults > > > Key: TS-820 > URL: https://issues.apache.org/jira/browse/TS-820 > Project: Traffic Server > Issue Type: Bug >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 3.1.0 > > > It seems modifying the default log buffer size makes things much more > unstable than previously thought. We should restore the old defaults, and > look into figuring out why the log buffer size is so finicky later. See > TS-777 for some details on that. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-830) traffic_line -r returns "Variable Not Found", even if it's a permission issue
traffic_line -r returns "Variable Not Found", even if it's a permission issue - Key: TS-830 URL: https://issues.apache.org/jira/browse/TS-830 Project: Traffic Server Issue Type: Bug Components: Management Affects Versions: 3.1.0, 2.1.9 Reporter: Igor Galić Priority: Minor Example: {noformat} i.galic@pheme ~ % /opt/bw/bin/traffic_line -r proxy.config.dns.nameservers /opt/bw/bin/traffic_line: Variable Not Found 1 i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r proxy.config.dns.nameservers NULL i.galic@pheme ~ % sudo /opt/bw/bin/traffic_line -r proxy.config.dns.nameservers /opt/bw/bin/traffic_line: Variable Not Found {noformat} I propose we tell the user, when it's actually a permission problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-837) ATS fails to compile with gcc 4.6.1
ATS fails to compile with gcc 4.6.1 --- Key: TS-837 URL: https://issues.apache.org/jira/browse/TS-837 Project: Traffic Server Issue Type: Bug Affects Versions: 3.1.0, 3.0.0 Environment: Linux, Debian, Amd64 + GCC 4.6.1 Reporter: Igor Galić {noformat} In file included from ../../proxy/ControlMatcher.h:104:0, from ../../proxy/ParentSelection.h:37, from P_Socks.h:30, from P_Net.h:106, from Connection.cc:34: ../../proxy/hdrs/HTTP.h: In member function 'INK_MD5 HTTPInfo::object_key_get()': ../../proxy/hdrs/HTTP.h:1375:24: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] ../../proxy/hdrs/HTTP.h: In member function 'int64_t HTTPInfo::object_size_get()': ../../proxy/hdrs/HTTP.h:1405:24: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] ../../proxy/hdrs/HTTP.h: In member function 'void HTTPInfo::object_size_set(int64_t)': ../../proxy/hdrs/HTTP.h:1422:51: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] cc1plus: all warnings being treated as errors *** [Connection.o] Error 1 make[2]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore/net' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore' make: *** [all-recursive] Error 1 {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-837) ATS fails to compile with gcc 4.6.1 with --enable-debug
[ https://issues.apache.org/jira/browse/TS-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-837: -- Summary: ATS fails to compile with gcc 4.6.1 with --enable-debug (was: ATS fails to compile with gcc 4.6.1) > ATS fails to compile with gcc 4.6.1 with --enable-debug > --- > > Key: TS-837 > URL: https://issues.apache.org/jira/browse/TS-837 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 3.1.0, 3.0.0 > Environment: Linux, Debian, Amd64 + GCC 4.6.1 >Reporter: Igor Galić > > {noformat} > In file included from ../../proxy/ControlMatcher.h:104:0, > from ../../proxy/ParentSelection.h:37, > from P_Socks.h:30, > from P_Net.h:106, > from Connection.cc:34: > ../../proxy/hdrs/HTTP.h: In member function 'INK_MD5 > HTTPInfo::object_key_get()': > ../../proxy/hdrs/HTTP.h:1375:24: error: dereferencing type-punned pointer > will break strict-aliasing rules [-Werror=strict-aliasing] > ../../proxy/hdrs/HTTP.h: In member function 'int64_t > HTTPInfo::object_size_get()': > ../../proxy/hdrs/HTTP.h:1405:24: error: dereferencing type-punned pointer > will break strict-aliasing rules [-Werror=strict-aliasing] > ../../proxy/hdrs/HTTP.h: In member function 'void > HTTPInfo::object_size_set(int64_t)': > ../../proxy/hdrs/HTTP.h:1422:51: error: dereferencing type-punned pointer > will break strict-aliasing rules [-Werror=strict-aliasing] > cc1plus: all warnings being treated as errors > *** [Connection.o] Error 1 > make[2]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore/net' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/netsrc/trafficserver-3.0.0/iocore' > make: *** [all-recursive] Error 1 > {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-838) [GSoC] Create a port of mod_security as Apache TrafficServer plugin
[GSoC] Create a port of mod_security as Apache TrafficServer plugin --- Key: TS-838 URL: https://issues.apache.org/jira/browse/TS-838 Project: Traffic Server Issue Type: Wish Components: Plugins Reporter: Igor Galić ModSecurity is a Web Application Firewall (WAF), which is currently natively implemented as Apache httpd module. It is mostly used to protect multiple back-end applications from a single entry point on a proxy-server. This alone makes Traffic Server the ideal platform for a port. For reference, see https://www.modsecurity.org/tracker/browse/MODSEC-250 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-842) remove uninstall target from build
remove uninstall target from build -- Key: TS-842 URL: https://issues.apache.org/jira/browse/TS-842 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 3.0.0, 3.1.0 Reporter: Igor Galić Assignee: Igor Galić Fix For: 3.1.0 Traffic Server currently has an uninstall target. Under certain layout choices this can wreck havoc. I propose we remove it, since developer usually build for /opt/foo or /opt/foo-version, and end-users should use their appropriate package manager. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-842) remove uninstall target from build
[ https://issues.apache.org/jira/browse/TS-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-842: -- Affects Version/s: (was: 3.1.0) Backport to Version: 3.0.1 (was: 3.0.0) Fixed in trunk, proposed for backport. > remove uninstall target from build > -- > > Key: TS-842 > URL: https://issues.apache.org/jira/browse/TS-842 > Project: Traffic Server > Issue Type: Bug > Components: Build >Affects Versions: 3.0.0 >Reporter: Igor Galić >Assignee: Igor Galić > Fix For: 3.1.0 > > > Traffic Server currently has an uninstall target. Under certain layout > choices this can wreck havoc. > I propose we remove it, since developer usually build for /opt/foo or > /opt/foo-version, and end-users should use their appropriate package manager. -- 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-tabpanel&focusedCommentId=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): > id="proxy.config.watch_script">proxy.config.watch_script > STRING > Default: traffic_cop > The name of the executable that runs the traffic_cop > process. > 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: > id="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. > > 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] [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-tabpanel&focusedCommentId=13052450#comment-13052450 ] Igor Galić commented on TS-847: --- tested trunk with multiple different servers: works every time. > 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-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: -- Backport to Version: (was: 3.0.1) Fix Version/s: 3.0.1 > 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, 3.0.1 > > 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