Re: Deprecated InkAPI / ts.h functions?
+1 on removing them since better alternatives exist and these were deprecated back in the INKT days. -George On 6/17/10 7:26 PM, Leif Hedstrom wrote: On 06/16/2010 12:14 AM, Nick Kew wrote: On 16 Jun 2010, at 01:05, Leif Hedstrom wrote: Hi, there's a fairly large number of APIs in InkAPI.cc / ts.h which are marked deprecated. The fact that they are deprecated implies that they were removed quite a while ago during Inktomi's release cycles. Should we still keep these for the v2.2 release, and nuke them for v3.0? Or nuke'em now and avoid having to deal with people using deprecated APIs in the plugins (they are all documented as deprecated already)? This raises the question: does trafficserver have a published policy on API/ABI stability? Under what circumstances is/isn't it promised? Anyone else have any thoughts / comments on this topic ? Unless it gets voted down, I'll file a bug and list the APIs that we'd remove from the 2.2 release. Yes, it's semi painful, but I think in the long term, it helps developers not use APIs that we no longer support (and which have better versions anyways). -- leif
Re: [VOTE] Release candidate for 2.1.1-unstable (dev release)
+1 on latest RC. Checks out on Ubuntu(9.04), FreeBSD(7.2), OSX(10.5) and OpenSolaris(osol0906). -George On 6/3/10 12:48 PM, Leif Hedstrom wrote: On 06/02/2010 08:41 PM, John Plevyak wrote: +1 all checks out for me We fixed a couple of bugs in the release candidate, new bits (and sigs) are available on http://people.apache.org/~zwoop/ Stil aiming for a release on Monday. -- Leif -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAABCgAGBQJMCAWeAAoJEFM97xVde7xaMXsQAKPwyEZVu7ByO6bQ22RBBkQv dMf8ojjDqWoZ1MyPZNwEEiRRH4eKHhKZUbT90uvj3rBiUTpUVUzlTi+2EETU8/aG KHzibO0748k4CCLCd0FyuW313toNuiv09yoMTuoIFIXOUefXjc2Sss/2Tvd2PX6g 3lVz5qBlVy+2hvMw0sVqWKTmanZGyqkjRhnygoqsUKHm0xZNvALVUdbQtIFyo7yl vwt8YvMYQXKrBuGbRZ0W3gh8oiOJmo1n8x6s8DErXBIZKZgCrWCQvsTEkoySauqK t0oVJH2a3iIIEeEsYflPKV3DcE13QEI+1VPkCSL6GS/WBev63URU8mJj3GeL2uwT jDYUEdi4yGQrb3TjOFA8Zu3P/I2dw46cTSZkpUnFSygAjXL/AvBZfGWyJXWGbaDx 7csa/jZxoHQftCVVScvZJztnVfdWW5/HKxyErsawuziqKGDPUQ8Bx6Im0y6gNof9 aFk9VtFJ+d3DAph4Rd3lWNEjhyXuIQVf8zzCzupZI0oy8Mp5s5VUxAvMV33wyb2Q xv/8z0gXzD519h2g6iKMhEY752Ozma/fXZLJb5XxjtovJ3ossLWdHojmr9CzxuW6 DHCo+g5Ta9VZMKVM50NjuzNHAJMEDRi+aGOmaGwcr9ES7AbJTPxyMoLt3z8TrLky /HEg/Ak1p5KdT9OYXppT =ULyz -END PGP SIGNATURE- MD5: e3118fa21e2a47c17b728503fa1d0e74 *trafficserver-2.1.1-unstable.tar.bz2 SHA1: c4a7d7cca2b7c85e0a1b171364ec79bdb115cfb4 *trafficserver-2.1.1-unstable.tar.bz2
Re: 2.1.0 Segfaulting in regression tests
Hi Alan, Can you file this as a Jira Ticket and provide as much as possible the necessary repro environment, code line, etc. thanks, -George On 5/19/10 8:14 PM, Alan M. Carroll wrote: Yes. Wednesday, May 19, 2010, 9:28:42 PM, you wrote: On 05/19/2010 07:33 PM, Alan M. Carroll wrote: I am trying to run regression tests (traffic_server -R 1) but it segfaults in Cache_part. According to TS-74 for the 'Cache_part' regression test to pass a cache storage has to be allocated 128MB. I checked there is a cache.db file that is 144M. Does this really mean a cache storage partition? And by pass does it mean that absent that cache storage a segfault (as opposed to a FAIL) is to be expected? Does by chance your stack trace look anything like this? 0 RegressionSM::run (this=0x7fffc8013850) at RegressionSM.cc:174 #1 0x004f8de9 in RegressionSM::regression_sm_waiting (this=0x7fffc8013850, event=value optimized out, data=value optimized out) at RegressionSM.cc:87 #2 0x006c7824 in handleEvent (this=0x7640e010, e=0x7fff9c069370, calling_code=2) at I_Continuation.h:147 #3 EThread::process_event (this=0x7640e010, e=0x7fff9c069370, calling_code=2) at UnixEThread.cc:143 #4 0x006c8333 in EThread::execute (this=0x7640e010) at UnixEThread.cc:220 #5 0x006c63aa in spawn_thread_internal (a=0xbbbf00) at Thread.cc:85 #6 0x003cc2e06a3a in start_thread (arg=0x74df7710) at pthread_create.c:297 #7 0x003cc22de62d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #8 0x in ?? () -- leif
Re: Using access instead stat for checking the resource existance
+1 -George On 5/19/10 3:09 AM, Mladen Turk wrote: Hi, We use stat all over the places for checking the presence of the file or directory. I propose we use access(path, R_OK [| W_OK]) instead, since the check is done with the real user id. Comments? Regards
Re: stdint.h please vote
Late but +1 -George On 5/19/10 9:57 AM, Leif Hedstrom wrote: On 05/19/2010 10:31 AM, Bryan Call wrote: On 05/19/2010 09:14 AM, John Plevyak wrote: Yes we will change INXXX_MAX etc. Unfortunately int64 is not standard. So we have a couple alternatives. 1) use nonstandard types where typedef long long int int64; typedef int int32; typedef short int16; typedef char int8; etc. which work on every system and which permit seamless printf using %lld and %d. This is the way we do it now. +1 - This is the lesser of the evils... +1, less evil == good. -- leif
Re: Removing DIR_SEP code
+1 Yes the DIR_SEP was for windows. Path handling, etc can be re-done if/when the windows port is done. -G On 5/18/10 10:37 PM, Mladen Turk wrote: Hi, I propose we remove all DIR_SEP code and just use the slash directly. The only reason for DIR_SEP can be windows, but I propose that for windows we create a private set of posix_path_to_windows_path_and_vice_versa set of functions which would allow proper path construction (eg, using \\?\ prefix for 260+ char paths etc.) at runtime. Comments? Regards
Re: Validating submitted patches
The original testing framework does not exist anymore. Currently only regression/unit tests in traffic_server are available. You can run them by invoking 'traffic_server -R 1' after an install. Currently only 4 of them related to the SDK fail. See https://issues.apache.org/jira/browse/TS-74 The best example of regression tests are the SDK API ones (proxy/InkAPITest.cc). Information about Regression/unit tests needs to be pulled out into a document/wiki/etc. -George On 5/11/10 3:03 PM, Alan M. Carroll wrote: I am trying to get my patches for a couple of the bugs I filed ready to submit and I thought perhaps I would test them a bit first. But I can't figure out how to get the test framework up. The instructions in test/deft seem out of date. Most particularly are the instructions to run gmake in the test directory, even though there are no makefiles (not even a Makefile.am) there. There is no configure in test/deft to generate a Makefile from the Makefile.am that is in that directory. Is the test framework not in working order? If so, what is the expected test procedure before submitting a patch? I only have the toplevel 'traffic' directory locally. Is there some test support in the 'site' or 'plugins' TLD?
Re: 2.1.0-unstable
+1 Tested: * platforms: ubuntu(9.0.4), OSX(10.5), FreeBSD(7.2), OpenSolaris(osol0906) * sig hashes * followed INSTALL procedures for the platforms above * tested forward proxying via browser, etc. -George On 5/13/10 11:27 AM, Bryan Call wrote: Tested stuff on my system (Fedora 12 x86_64) and it looks good: - checked the hashes - untared and built with defaults - installed and ran benchmarks proxying to the origin and caching - checked file ownership and permissions -Bryan On May 13, 2010, at 10:45 AM, John Plevyak wrote: Please take a look at http://people.apache.org/~jplevyak/ which contains the NEW candidate 2.1.0 unstable release. This is an unstable release, so it still contains a number of issues, but no serious regressions. Please consider it for release, I'll send out for a vote if I don't get a negative response by the end of day. john
Re: Localizing apr_foo.m4 macros
I haven't looked at those files in detail but if you think it is too much work to make those macros not hardcoded to Apache Httpd then localizing is probably okay for now. -George On 5/10/10 9:03 AM, Mladen Turk wrote: Hi, Reusing is good, but I found out that one of the very handy functions we could use (APR_LAYOUT/APR_ENABLE_LAYOUT) has some hard-coded Apache Httpd dependency. Namely the package prefix is hard-coded to 'apache2' meaning it would need rewrite to be be usable. Sure, we could modify that particular function and change apache2 to trafficserver plus adding pkg* layout options, but then it won't be the same file any more. Perhaps we could name space protect it, rename all functions from APR_ to ATS_ and cleanup those files, by removing functions that are not used. WDYT? Regards
Re: SocketManager::close vs. SocketManager::fast_close
There were fast path(s) in the SocketXXX code when used with a kernel non-native BSD-TCP stack on certain platforms. In the current cleansed code base this is no longer applicable/supported. -George On 5/4/10 8:26 AM, Alan M. Carroll wrote: I can't see what the functional difference between these methods is, other than close() printing an error message if the caller tries to close STDIN (file descriptor 0). Surely that check isn't enough to make one fast and the other not.
Re: if (Graduation == Beer) {
+1 -George On 5/3/10 4:28 PM, Leif Hedstrom wrote: Hi all, a few of us are getting together for a beer or two on Monday 5/10, 6.30pm at the Steelhead brewery in Burlingame: http://www.steelheadbrewery.com/burlingame.htm Maybe we can get a roll call who's able to come, if there are more than 8 of us, we'll want to make reservations. I know John, Bryan, Steve and I will be there, and the more the merrier of course. The official excuse for this beer outage is to celebrate our graduation from Incubator, so please come celebrate! :) Cheers! -- leif
[jira] Updated: (TS-328) add the example directory into the build and fix and compilation bugs
[ https://issues.apache.org/jira/browse/TS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-328: --- Attachment: 0001-TS328_example_gp_diff4.patch This patch '0001-TS328_example_gp_diff4.patch' fixes a few more compilations errors after applying '003-example-bcall.patch' first. -George add the example directory into the build and fix and compilation bugs - Key: TS-328 URL: https://issues.apache.org/jira/browse/TS-328 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Assignee: Bryan Call Fix For: 2.1.0 Attachments: 0001-TS328_example_gp_diff4.patch, 001-example-bcall.patch, 002-example-bcall.patch, 003-example-bcall.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-324) FTP cleanup
[ https://issues.apache.org/jira/browse/TS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12862488#action_12862488 ] George Paul commented on TS-324: Can we leaf the FTP support in the 'hdrs' library i.e. 'proxy/hdrs'. I believe it would be best to leave protocol support where it is isolated in library in case someone wants to write a plugin for FTP support or reuse the 'hdrs' lib somewhere else. -George FTP cleanup --- Key: TS-324 URL: https://issues.apache.org/jira/browse/TS-324 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 2.1.0 Attachments: DIFF There is still a lot of FTP code left, even though all support for FTP is gone. We should clean up these remnants. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-324) FTP cleanup
[ https://issues.apache.org/jira/browse/TS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12862502#action_12862502 ] George Paul commented on TS-324: Other than my comments above about leaving in the FTP support in the hdrs lib the patch looks good. Reviewed and tested on ubuntu904, FreeBSD(7.2), OpenSolaris(osol0906) and OSX(10.5). -George FTP cleanup --- Key: TS-324 URL: https://issues.apache.org/jira/browse/TS-324 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 2.1.0 Attachments: DIFF There is still a lot of FTP code left, even though all support for FTP is gone. We should clean up these remnants. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-324) FTP cleanup
[ https://issues.apache.org/jira/browse/TS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12862516#action_12862516 ] George Paul commented on TS-324: Discussed this issue on IRC. +1 on patch. Good to go. -George FTP cleanup --- Key: TS-324 URL: https://issues.apache.org/jira/browse/TS-324 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 2.1.0 Attachments: DIFF There is still a lot of FTP code left, even though all support for FTP is gone. We should clean up these remnants. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-328) add the example directory into the build and fix and compilation bugs
[ https://issues.apache.org/jira/browse/TS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12862520#action_12862520 ] George Paul commented on TS-328: I ran into problems trying to do build in a separate build directory which I do by default i.e. not in the same directory as source is located. It looks like the include directories and source locations need to be prefixed with $(top_srcdir) in the Makefile.am(s). i.e. mkdir build; cd build; ../configure make e.g. traffic/example/Makefile.am ... API_INC=$(top_srcdir)/proxy/api/include ln -sfn . $(top_srcdir)/proxy/api/include/ts e.g. traffic/example/add-header/Makefile.am ... $(CC) $(CFLAGS) -I$(API_INC) -o add-header.o -c $(top_srcdir)/example/add-header/add-header.c ... add the example directory into the build and fix and compilation bugs - Key: TS-328 URL: https://issues.apache.org/jira/browse/TS-328 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Assignee: Bryan Call Fix For: 2.1.0 Attachments: 001-example-bcall.patch, 002-example-bcall.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-292) --enable-standalone-iocore is broken and more generally the iocore modularization needs work
[ https://issues.apache.org/jira/browse/TS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul reassigned TS-292: -- Assignee: George Paul (was: John Plevyak) --enable-standalone-iocore is broken and more generally the iocore modularization needs work Key: TS-292 URL: https://issues.apache.org/jira/browse/TS-292 Project: Traffic Server Issue Type: Bug Reporter: John Plevyak Assignee: George Paul --enable-standalone-iocore is broken and more generally the iocore modularization needs work. This is an umbrella bug for unraveling dependencies in the iocore. More general system modularization should be covered by a different jira ticket. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Apache Traffic Server Mailing lists
Hi all, Moving forward the Apache Traffic Server will have the following mailing lists migrated from the old incubator mailing ones. us...@trafficserver.apache.org d...@trafficserver.apache.org comm...@trafficserver.apache.org priv...@trafficserver.apache.org I would like to propose a new mailing lists for Jira Tickets similar to what a few other Apache projects have done. iss...@trafficserver.apache.org Thoughts? cheers, -George
Re: Apache Traffic Server Mailing lists
+1 also. -George On 4/22/10 3:37 PM, Leif Hedstrom wrote: On 04/22/2010 04:32 PM, Miles Libbey wrote: +1 on issues. We should also create secur...@trafficserver.apache.org and annou...@trafficserver.apache.org +1 on these as well. -- Leif
[jira] Updated: (TS-173) REGRESSION_RESULT SDK_API_HttpTxnCache: FAILED
[
https://issues.apache.org/jira/browse/TS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-173:
---
Fix Version/s: 2.1.0
(was: 2.0.0)
Move to 2.1.
REGRESSION_RESULT SDK_API_HttpTxnCache: FAILED
--
Key: TS-173
URL: https://issues.apache.org/jira/browse/TS-173
Project: Traffic Server
Issue Type: Bug
Components: InkAPI
Affects Versions: 2.0.0a
Environment: All
Reporter: George Paul
Fix For: 2.1.0
The following SDK API regression tests fails.
env
TS_ROOT=/home/georgep/projects/apache/trafficserver/git_trunk_TS74/trafficserver/ubuntu904/test_dir/usr/local
./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpTxnCache
REGRESSION_TEST initialization begun
REGRESSION TEST SDK_API_HttpTxnCache started
[SDK_API_HttpTxnCache] INKHttpTxnCacheLookupStatusGet : [TestCase1] PASS
{ ok }
[SDK_API_HttpTxnCache] INKHttpTxnCacheLookupStatusGet : [TestCase2] FAIL
{ Incorrect Value returned by INKHttpTxnCacheLookupStatusGet }
REGRESSION_RESULT SDK_API_HttpTxnCache:FAILED
REGRESSION_TEST DONE: FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-192) REGRESSION_RESULT SDK_API_HttpSsn: FAILED
[ https://issues.apache.org/jira/browse/TS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-192: --- Fix Version/s: 2.1.0 (was: 2.0.0) Move to 2.1. REGRESSION_RESULT SDK_API_HttpSsn: FAILED - Key: TS-192 URL: https://issues.apache.org/jira/browse/TS-192 Project: Traffic Server Issue Type: Bug Components: InkAPI Affects Versions: 2.0.0a Environment: All Reporter: George Paul Fix For: 2.1.0 The following SDK API regression tests fails. This did not happen before, but testing on older SVN revision (r909505) has shown it existed when working on TS-74. Possibly a timing issue in the test. env TS_ROOT=/home/georgep/projects/apache/trafficserver/svn_trunk_r909505/traffic/ubuntu904/test_dir/usr/local ./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpSsn REGRESSION_TEST initialization begun REGRESSION TEST SDK_API_HttpSsn started REGRESSION_RESULT SDK_API_HttpSsn: FAILED REGRESSION_TEST DONE: FAILED -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-174) REGRESSION_RESULT SDK_API_HttpHookAdd: FAILED
[
https://issues.apache.org/jira/browse/TS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-174:
---
Fix Version/s: 2.1.0
(was: 2.0.0)
Move to 2.1.
REGRESSION_RESULT SDK_API_HttpHookAdd: FAILED
-
Key: TS-174
URL: https://issues.apache.org/jira/browse/TS-174
Project: Traffic Server
Issue Type: Bug
Components: InkAPI
Affects Versions: 2.0.0a
Environment: All
Reporter: George Paul
Fix For: 2.1.0
The following SDK API regression tests fails.
env
TS_ROOT=/home/georgep/projects/apache/trafficserver/git_trunk_TS74/trafficserver/ubuntu904/test_dir/usr/local
./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpHookAdd
REGRESSION_TEST initialization begun
REGRESSION TEST SDK_API_HttpHookAdd started
[SDK_API_HttpHookAdd] INKHttpTxnClientReqGet : [TestCase1] PASS { ok }
[SDK_API_HttpHookAdd] INKHttpTxnClientIncomingPortGet : [TestCase1] PASS
{ ok }
[SDK_API_HttpHookAdd] INKHttpTxnClientRemotePortGet : [TestCase1] PASS {
ok }
[SDK_API_HttpHookAdd] INKHttpTxnClientIPGet : [TestCase1] PASS { ok }
[SDK_API_HttpHookAdd] INKHttpTxnServerIPGet : [TestCase1] PASS { ok }
[SDK_API_HttpHookAdd] INKHttpTxnServerReqGet : [TestCase1] PASS { ok }
[SDK_API_HttpHookAdd] INKHttpTxnNextHopIPGet : [TestCase1] PASS { ok }
[SDK_API_HttpHookAdd] INKHttpTxnServerRespGet : [TestCase1] PASS { ok }
[SDK_API_HttpHookAdd] INKHttpTxnClientRespGet : [TestCase1] PASS { ok }
[SDK_API_HttpHookAdd] INKHttpHookAdd : [TestCase1] FAIL { Hooks not
called or request failure. Hook mask = 7 }
[SDK_API_HttpHookAdd] INKHttpTxnReenable : [TestCase1] PASS { ok }
REGRESSION_RESULT SDK_API_HttpHookAdd: FAILED
REGRESSION_TEST DONE: FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-171) REGRESSION_RESULT SDK_API_HttpAltInfo: FAILED
[
https://issues.apache.org/jira/browse/TS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-171:
---
Fix Version/s: 2.1.0
(was: 2.0.0)
Move to 2.1.
REGRESSION_RESULT SDK_API_HttpAltInfo: FAILED
-
Key: TS-171
URL: https://issues.apache.org/jira/browse/TS-171
Project: Traffic Server
Issue Type: Bug
Components: InkAPI
Affects Versions: 2.0.0a
Environment: All
Reporter: George Paul
Fix For: 2.1.0
The following SDK API regression tests fails.
env
TS_ROOT=/home/georgep/projects/apache/trafficserver/git_trunk_TS74/trafficserver/ubuntu904/test_dir/usr/local
./test_dir/usr/local/bin/traffic_server -R 1 -r SDK_API_HttpAltInfo
REGRESSION_TEST initialization begun
REGRESSION TEST SDK_API_HttpAltInfo started
[SDK_API_HttpAltInfo] INKHttpAltInfo : [All] FAIL { Test not executed
even once }
REGRESSION_RESULT SDK_API_HttpAltInfo: FAILED
REGRESSION_TEST DONE: FAILED
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 2.0.0 release
+1 We should review the jira issues for 2.0.0 release and determine the final 2.0.0 list. -George On 3/31/10 7:12 PM, Leif Hedstrom wrote: Hi all, I'd like to suggest that we start the 2.0.0 release process on 4/12, and wanted to see what everyone thinks about that. I was going to suggest we wait until after graduation, but I'm not sure I want to wait for that, particularly if there are some details that would prevent us from going to the board with the resolution on 4/21 (which will be a close call anyways :). Thoughts? -- leif P.s Make sure you update and vote on the 2.0.x STATUS file, so we can backport any bugs that must go into the 2.0.0 final release.
[jira] Commented: (TS-286) Seg fault on startup on OSX inside RecSetRawStatSum
[
https://issues.apache.org/jira/browse/TS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852407#action_12852407
]
George Paul commented on TS-286:
Looked at the code and the mutex needs to be initialized. The patch works for
me also and is good to check in.
-George
Seg fault on startup on OSX inside RecSetRawStatSum
---
Key: TS-286
URL: https://issues.apache.org/jira/browse/TS-286
Project: Traffic Server
Issue Type: Bug
Reporter: Eric Balsa
Fix For: 2.1.0
Attachments: TS-286.patch
OS X debug (--enable-debug) build:
Getting the following segfault about 5 seconds after startup with latest
trunk:
#0 0x7fff88b4cfe6 in __kill ()
#1 0x7fff88bede32 in abort ()
#2 0x000100280639 in ink_mutex_acquire (m=0x100d56368) at ink_mutex.h:96
#3 0x000100280924 in raw_stat_clear_sum (rsb=0x100d56350, id=0) at
RecProcess.cc:126
#4 0x000100280a0c in RecSetRawStatSum (rsb=0x100d56350, id=0, data=0) at
RecProcess.cc:592
#5 0x0001002588a3 in register_net_stats () at Net.cc:66
#6 0x000100258e04 in ink_net_init (version=16842752) at Net.cc:152
#7 0x000100075f9f in main (argc=1, argv=0x7fff5fbff948) at Main.cc:1896
(gdb) fr 4
#4 0x000100280a0c in RecSetRawStatSum (rsb=0x100d56350, id=0, data=0) at
RecProcess.cc:592
592 raw_stat_clear_sum(rsb, id);
(gdb) p *rsb
$12 = {
ethr_stat_offset = 2920,
global = 0x100d563b0,
num_stats = 0,
max_stats = 16,
mutex = {
__sig = 0,
__opaque = '\0' repeats 55 times
}
}
(gdb) fr 2
#2 0x000100280639 in ink_mutex_acquire (m=0x101801448) at ink_mutex.h:96
96abort();
(gdb) l
91
92static inline int
93ink_mutex_acquire(ink_mutex * m)
94{
95 if (pthread_mutex_lock(m) != 0) {
96abort();
97 }
98 return 0;
99}
Looks like the mutex for rsb is NULL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Graduate Apache Traffics Server as TLP
[X] +1 to recommend Apache Traffic Server graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) -George
[jira] Resolved: (TS-285) EC2 Documentation on AMIs which have been compiled and bundled.
[ https://issues.apache.org/jira/browse/TS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-285. Resolution: Fixed Fix Version/s: 2.1.0 EC2 Documentation on AMIs which have been compiled and bundled. --- Key: TS-285 URL: https://issues.apache.org/jira/browse/TS-285 Project: Traffic Server Issue Type: Bug Environment: EC2 Reporter: Jason Giedymin Assignee: Jason Giedymin Fix For: 2.1.0 Attachments: readme_ec2.txt Attached is 'readme_ec2.txt' A readme file which explains the AMIs which were built. Feel free to rename the file, fix any spelling. I'm unsure exactly where this will go, perhaps in /contrib? Make it part of the master readme? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-285) EC2 Documentation on AMIs which have been compiled and bundled.
[ https://issues.apache.org/jira/browse/TS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul reassigned TS-285: -- Assignee: Jason Giedymin EC2 Documentation on AMIs which have been compiled and bundled. --- Key: TS-285 URL: https://issues.apache.org/jira/browse/TS-285 Project: Traffic Server Issue Type: Bug Environment: EC2 Reporter: Jason Giedymin Assignee: Jason Giedymin Fix For: 2.1.0 Attachments: readme_ec2.txt Attached is 'readme_ec2.txt' A readme file which explains the AMIs which were built. Feel free to rename the file, fix any spelling. I'm unsure exactly where this will go, perhaps in /contrib? Make it part of the master readme? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-278) contrib update
[ https://issues.apache.org/jira/browse/TS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-278. Resolution: Fixed Fix Version/s: 2.1.0 Added fedora EC2 compatibility Added EC2 detection option contrib update -- Key: TS-278 URL: https://issues.apache.org/jira/browse/TS-278 Project: Traffic Server Issue Type: Bug Affects Versions: 2.0.0 Environment: All/Any Reporter: Jason Giedymin Assignee: Jason Giedymin Priority: Minor Fix For: 2.1.0 Attachments: install_trafficserver.sh Update to contrib script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-263) Traffic server dying
[
https://issues.apache.org/jira/browse/TS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul reassigned TS-263:
--
Assignee: George Paul
Traffic server dying
Key: TS-263
URL: https://issues.apache.org/jira/browse/TS-263
Project: Traffic Server
Issue Type: Bug
Affects Versions: 2.1.0
Environment: Ubuntu 8.04, Linux 2.6.18-028stab067.4-PAE #1 SMP Thu
Jan 14 22:09:19 MSK 2010 i686 GNU/Linux - Virtuozzo VPS
Reporter: Marcus Clyne
Assignee: George Paul
Priority: Blocker
Fix For: 2.0.0
Attachments: 0001-TS263_patch1.diff.patch, Kernel 2.6.21.7-2 Errors
log with Patch (p1).txt, records.config, TS-263__configure.ac.patch
Having compiled TS, and started the server, I get the following errors both
in the syslog and in traffic.out (some of the messages in traffic.out are
very similar to those in the syslog) :
in the syslog :
Mar 20 19:36:47 tagmata traffic_cop[1795]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:09:00)] ---
Mar 20 19:36:47 tagmata traffic_cop[1795]: traffic_manager not running,
making sure traffic_server is dead
Mar 20 19:36:47 tagmata traffic_cop[1795]: spawning traffic_manager
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: --- Manager Starting ---
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:11:51)
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE:
RLIMIT_NOFILE(7):cur(1),max(1)
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} STATUS: opened
var/log/trafficserver/manager.log
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE: updated
diags config
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.18-028stab067.4-PAE'
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::listenForProxy] Listening on port: 8080
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[TrafficManager] Setup complete
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: --- Server Starting ---
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:13:15)
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} STATUS: opened
var/log/trafficserver/diags.log
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: updated
diags config
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: cache
clustering disabled
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: clearing
statistics
Mar 20 19:36:49 tagmata traffic_server[1808]: FATAL:
../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:70: failed assert
`(evfd = eventfd(0,0)) = 0`
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[Alarms::signalAlarm] Server Process was reset
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
in traffic.out :
[Mar 20 20:02:22.778] Manager {3080124096} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[TrafficServer] using root directory '/simpl/apps/trafficserver/trunk'
[Mar 20 20:02:24.830] {1080614544} STATUS: opened
var/log
[jira] Resolved: (TS-263) Traffic server dying
[
https://issues.apache.org/jira/browse/TS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul resolved TS-263.
Resolution: Fixed
Fix Version/s: (was: 2.0.0)
2.1.0
These fixes are only applicable to 2.1/trunk branch where eventfd() support was
added and used as the default instead of default pipes usage in 2.0.x.
-George
Traffic server dying
Key: TS-263
URL: https://issues.apache.org/jira/browse/TS-263
Project: Traffic Server
Issue Type: Bug
Affects Versions: 2.1.0
Environment: Ubuntu 8.04, Linux 2.6.18-028stab067.4-PAE #1 SMP Thu
Jan 14 22:09:19 MSK 2010 i686 GNU/Linux - Virtuozzo VPS
Reporter: Marcus Clyne
Assignee: George Paul
Priority: Blocker
Fix For: 2.1.0
Attachments: 0001-TS263_patch1.diff.patch, Kernel 2.6.21.7-2 Errors
log with Patch (p1).txt, records.config, TS-263__configure.ac.patch
Having compiled TS, and started the server, I get the following errors both
in the syslog and in traffic.out (some of the messages in traffic.out are
very similar to those in the syslog) :
in the syslog :
Mar 20 19:36:47 tagmata traffic_cop[1795]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:09:00)] ---
Mar 20 19:36:47 tagmata traffic_cop[1795]: traffic_manager not running,
making sure traffic_server is dead
Mar 20 19:36:47 tagmata traffic_cop[1795]: spawning traffic_manager
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: --- Manager Starting ---
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:11:51)
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE:
RLIMIT_NOFILE(7):cur(1),max(1)
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} STATUS: opened
var/log/trafficserver/manager.log
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE: updated
diags config
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.18-028stab067.4-PAE'
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::listenForProxy] Listening on port: 8080
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[TrafficManager] Setup complete
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: --- Server Starting ---
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:13:15)
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} STATUS: opened
var/log/trafficserver/diags.log
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: updated
diags config
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: cache
clustering disabled
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: clearing
statistics
Mar 20 19:36:49 tagmata traffic_server[1808]: FATAL:
../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:70: failed assert
`(evfd = eventfd(0,0)) = 0`
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[Alarms::signalAlarm] Server Process was reset
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
in traffic.out :
[Mar 20 20:02:22.778] Manager {3080124096} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 20 20:02:22.778
[jira] Resolved: (TS-264) Cannot compile with Libev
[ https://issues.apache.org/jira/browse/TS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-264. Resolution: Fixed Hi Marcus, This should be resolved if you follow the latest README.libev'. Please re-open if it does not work for you. regards, -George Cannot compile with Libev - Key: TS-264 URL: https://issues.apache.org/jira/browse/TS-264 Project: Traffic Server Issue Type: Bug Affects Versions: 2.1.0 Environment: Ubuntu 9.10, Linux 2.6.31-14-generic x86_64 and Ubuntu 8.04, 2.6.18-028stab067 32-bit Reporter: Marcus Clyne Assignee: George Paul Priority: Blocker Fix For: 2.1.0 I tried to compiled TS with libev on both my 64-bit laptop and 32-bit Virtuozzo VPS machines, but it failed to build. I get the following errors in both instances : rpath -Wl,/simpl/apps/pcre/8.02/lib -Wl,-rpath -Wl,/simpl/apps/sqlite/3.6.23/lib -Wl,-rpath -Wl,/simpl/apps/libev/3.9/lib ../iocore/net/libinknet.a(UnixNet.o): In function `PollCont::pollEvent(int, Event*)': /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/UnixNet.cc:116: undefined reference to `fd_reify' ../iocore/net/libinknet.a(UnixNet.o): In function `EventIO::modify(int)': /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: undefined reference to `fd_change' /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: undefined reference to `fd_change' ../iocore/net/libinknet.a(UnixNet.o): In function `NetHandler::mainNetEvent(int, Event*)': /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/UnixNet.cc:336: undefined reference to `fd_reify' ../iocore/net/libinknet.a(UnixNet.o): In function `EventIO::modify(int)': /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: undefined reference to `fd_change' /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: undefined reference to `fd_change' ../iocore/net/libinknet.a(UnixNetVConnection.o): In function `EventIO::modify(int)': /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: undefined reference to `fd_change' /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: undefined reference to `fd_change' /simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: undefined reference to `fd_change' ../iocore/net/libinknet.a(UnixNetVConnection.o):/simpl/src/trafficserver-trunk-build/2/iocore/net/../../../../trafficserver-trunk/iocore/net/P_UnixNet.h:545: more undefined references to `fd_change' follow collect2: ld returned 1 exit status make[3]: *** [traffic_server] Error 1 make[3]: Leaving directory `/mnt/data/simpl/src/trafficserver-trunk-build/2/proxy' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/mnt/data/simpl/src/trafficserver-trunk-build/2/proxy' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt/data/simpl/src/trafficserver-trunk-build/2' Build with : --enable-libev --with-pcre=/path/to/pcre -I/path/to/libev -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-127) Add back trace support for other platforms
[ https://issues.apache.org/jira/browse/TS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-127. Resolution: Fixed There is now initial backtrace support on all supported platforms using GCC. -George Add back trace support for other platforms -- Key: TS-127 URL: https://issues.apache.org/jira/browse/TS-127 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Environment: FreeBSD, OSX, OpenSolaris Reporter: George Paul Assignee: George Paul Fix For: 2.1.0 Back trace support similar to gdb backtrace() support should be added for FreeBSD, OSX and OpenSolaris in addition to the current Linux support. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-263) Traffic server dying
[
https://issues.apache.org/jira/browse/TS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12849206#action_12849206
]
George Paul commented on TS-263:
Jason,
I agree that as driver developer what you suggested above is the way to go. The
other way is to test for which eventfd() usage works in configure which is a
bit more work. I'm okay if you go the first route but make a note of it, maybe
in a comment.
-George
Traffic server dying
Key: TS-263
URL: https://issues.apache.org/jira/browse/TS-263
Project: Traffic Server
Issue Type: Bug
Affects Versions: 2.1.0
Environment: Ubuntu 8.04, Linux 2.6.18-028stab067.4-PAE #1 SMP Thu
Jan 14 22:09:19 MSK 2010 i686 GNU/Linux - Virtuozzo VPS
Reporter: Marcus Clyne
Priority: Blocker
Attachments: records.config
Having compiled TS, and started the server, I get the following errors both
in the syslog and in traffic.out (some of the messages in traffic.out are
very similar to those in the syslog) :
in the syslog :
Mar 20 19:36:47 tagmata traffic_cop[1795]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:09:00)] ---
Mar 20 19:36:47 tagmata traffic_cop[1795]: traffic_manager not running,
making sure traffic_server is dead
Mar 20 19:36:47 tagmata traffic_cop[1795]: spawning traffic_manager
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: --- Manager Starting ---
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:11:51)
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE:
RLIMIT_NOFILE(7):cur(1),max(1)
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} STATUS: opened
var/log/trafficserver/manager.log
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE: updated
diags config
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.18-028stab067.4-PAE'
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::listenForProxy] Listening on port: 8080
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[TrafficManager] Setup complete
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: --- Server Starting ---
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:13:15)
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} STATUS: opened
var/log/trafficserver/diags.log
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: updated
diags config
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: cache
clustering disabled
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: clearing
statistics
Mar 20 19:36:49 tagmata traffic_server[1808]: FATAL:
../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:70: failed assert
`(evfd = eventfd(0,0)) = 0`
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[Alarms::signalAlarm] Server Process was reset
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
in traffic.out :
[Mar 20 20:02:22.778] Manager {3080124096} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[TrafficServer] using
[jira] Updated: (TS-263) Traffic server dying
[
https://issues.apache.org/jira/browse/TS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-263:
---
Attachment: 0001-TS263_patch1.diff.patch
Hi folks,
Please try this patch '0001-TS263_patch1.diff.patch'
patch -p1 -i 0001-TS263_patch1.diff.patch
-George
Traffic server dying
Key: TS-263
URL: https://issues.apache.org/jira/browse/TS-263
Project: Traffic Server
Issue Type: Bug
Affects Versions: 2.1.0
Environment: Ubuntu 8.04, Linux 2.6.18-028stab067.4-PAE #1 SMP Thu
Jan 14 22:09:19 MSK 2010 i686 GNU/Linux - Virtuozzo VPS
Reporter: Marcus Clyne
Priority: Blocker
Attachments: 0001-TS263_patch1.diff.patch, records.config
Having compiled TS, and started the server, I get the following errors both
in the syslog and in traffic.out (some of the messages in traffic.out are
very similar to those in the syslog) :
in the syslog :
Mar 20 19:36:47 tagmata traffic_cop[1795]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:09:00)] ---
Mar 20 19:36:47 tagmata traffic_cop[1795]: traffic_manager not running,
making sure traffic_server is dead
Mar 20 19:36:47 tagmata traffic_cop[1795]: spawning traffic_manager
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: --- Manager Starting ---
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:11:51)
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE:
RLIMIT_NOFILE(7):cur(1),max(1)
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} STATUS: opened
var/log/trafficserver/manager.log
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE: updated
diags config
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.18-028stab067.4-PAE'
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::listenForProxy] Listening on port: 8080
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[TrafficManager] Setup complete
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: --- Server Starting ---
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:13:15)
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} STATUS: opened
var/log/trafficserver/diags.log
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: updated
diags config
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: cache
clustering disabled
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: clearing
statistics
Mar 20 19:36:49 tagmata traffic_server[1808]: FATAL:
../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:70: failed assert
`(evfd = eventfd(0,0)) = 0`
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[Alarms::signalAlarm] Server Process was reset
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
in traffic.out :
[Mar 20 20:02:22.778] Manager {3080124096} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[TrafficServer] using root directory '/simpl/apps/trafficserver/trunk'
[Mar 20 20:02:24.830] {1080614544} STATUS: opened
var/log/trafficserver
[jira] Commented: (TS-263) Traffic server dying
[
https://issues.apache.org/jira/browse/TS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12848497#action_12848497
]
George Paul commented on TS-263:
I should have mentioned to the change the assert check into printing out the
'errno' instead in case 'evfd 0' so we can see why the syscall is failing.
-G
Traffic server dying
Key: TS-263
URL: https://issues.apache.org/jira/browse/TS-263
Project: Traffic Server
Issue Type: Bug
Affects Versions: 2.1.0
Environment: Ubuntu 8.04, Linux 2.6.18-028stab067.4-PAE #1 SMP Thu
Jan 14 22:09:19 MSK 2010 i686 GNU/Linux - Virtuozzo VPS
Reporter: Marcus Clyne
Priority: Blocker
Attachments: records.config
Having compiled TS, and started the server, I get the following errors both
in the syslog and in traffic.out (some of the messages in traffic.out are
very similar to those in the syslog) :
in the syslog :
Mar 20 19:36:47 tagmata traffic_cop[1795]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:09:00)] ---
Mar 20 19:36:47 tagmata traffic_cop[1795]: traffic_manager not running,
making sure traffic_server is dead
Mar 20 19:36:47 tagmata traffic_cop[1795]: spawning traffic_manager
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: --- Manager Starting ---
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:11:51)
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE:
RLIMIT_NOFILE(7):cur(1),max(1)
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} STATUS: opened
var/log/trafficserver/manager.log
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE: updated
diags config
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.18-028stab067.4-PAE'
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::listenForProxy] Listening on port: 8080
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[TrafficManager] Setup complete
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: --- Server Starting ---
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:13:15)
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} STATUS: opened
var/log/trafficserver/diags.log
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: updated
diags config
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: cache
clustering disabled
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: clearing
statistics
Mar 20 19:36:49 tagmata traffic_server[1808]: FATAL:
../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:70: failed assert
`(evfd = eventfd(0,0)) = 0`
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[Alarms::signalAlarm] Server Process was reset
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
in traffic.out :
[Mar 20 20:02:22.778] Manager {3080124096} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[TrafficServer] using root directory '/simpl/apps/trafficserver/trunk'
[Mar 20 20:02:24.830] {1080614544} STATUS: opened
var/log
[jira] Commented: (TS-263) Traffic server dying
[
https://issues.apache.org/jira/browse/TS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12847950#action_12847950
]
George Paul commented on TS-263:
Hi Marcus,
Looking at the code path the problem is most likely a kernel version issue.
From the eventfd() man page it looks like for linux kernels =2.6.26 the
'flags' argument is unused and must be specified as zero. Try changing the line
'UnixEThread.cc:67' to
evfd = eventfd(0, 0);
recompile and test it out.
regards,
-George
Traffic server dying
Key: TS-263
URL: https://issues.apache.org/jira/browse/TS-263
Project: Traffic Server
Issue Type: Bug
Affects Versions: 2.1.0
Environment: Ubuntu 8.04, Linux 2.6.18-028stab067.4-PAE #1 SMP Thu
Jan 14 22:09:19 MSK 2010 i686 GNU/Linux - Virtuozzo VPS
Reporter: Marcus Clyne
Priority: Blocker
Attachments: records.config
Having compiled TS, and started the server, I get the following errors both
in the syslog and in traffic.out (some of the messages in traffic.out are
very similar to those in the syslog) :
in the syslog :
Mar 20 19:36:47 tagmata traffic_cop[1795]: --- Cop Starting [Version: Apache
Traffic Server - traffic_cop - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:09:00)] ---
Mar 20 19:36:47 tagmata traffic_cop[1795]: traffic_manager not running,
making sure traffic_server is dead
Mar 20 19:36:47 tagmata traffic_cop[1795]: spawning traffic_manager
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: --- Manager Starting ---
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:11:51)
Mar 20 19:36:47 tagmata traffic_manager[1797]: NOTE:
RLIMIT_NOFILE(7):cur(1),max(1)
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} STATUS: opened
var/log/trafficserver/manager.log
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE: updated
diags config
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
'2.6.18-028stab067.4-PAE'
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::listenForProxy] Listening on port: 8080
Mar 20 19:36:47 tagmata traffic_manager[1797]: {3079632576} NOTE:
[TrafficManager] Setup complete
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:48 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: --- Server Starting ---
Mar 20 19:36:49 tagmata traffic_server[1808]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 2.1.0 - (build # 2204 on Mar 20 2010 at
04:13:15)
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} STATUS: opened
var/log/trafficserver/diags.log
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: updated
diags config
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: cache
clustering disabled
Mar 20 19:36:49 tagmata traffic_server[1808]: {1080614544} NOTE: clearing
statistics
Mar 20 19:36:49 tagmata traffic_server[1808]: FATAL:
../../../../trafficserver/iocore/eventsystem/UnixEThread.cc:70: failed assert
`(evfd = eventfd(0,0)) = 0`
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR:
[Alarms::signalAlarm] Server Process was reset
Mar 20 19:36:49 tagmata traffic_manager[1797]: {3079632576} ERROR: (last
system error 2: No such file or directory)
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::startProxy] Launching ts process
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[LocalManager::pollMgmtProcessServer] New process connecting fd '14'
Mar 20 19:36:50 tagmata traffic_manager[1797]: {3079632576} NOTE:
[Alarms::signalAlarm] Server Process born
in traffic.out :
[Mar 20 20:02:22.778] Manager {3080124096} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last system error 2: No
such file or directory)
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: [Alarms::signalAlarm]
Server Process was reset
[Mar 20 20:02:22.778] Manager {3080124096} ERROR: (last
Re: draft of a new traffic server home page
Looks great Miles! Also looking at the Httpd home page (http://httpd.apache.org/) as reference. It would also be nice to have Security Reports section as a placeholder. They also have a Get Involved section but maybe that is similar the Contribute section? They also have Miscellaneous Section. regards, -George On 3/19/10 4:54 PM, Miles Libbey wrote: On Mar 19, 2010, at 2:36 PM, Leif Hedstrom wrote: One thing missing (I think): We need a section on the home page (or on a linked page) about all the current and older releases. Yes -- good one. I'll add a section for latest release. Will play with moving the download into that or keeping in the overview. Also, I had mocked up a download page (have not put that up anywhere yet) -- figuring it would have all the release descriptions -- but that may not yet have a link to it. miles
[jira] Commented: (TS-127) Add back trace support for other platforms
[ https://issues.apache.org/jira/browse/TS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845611#action_12845611 ] George Paul commented on TS-127: TS-244 Adds backtrace() support for FreeBSD and OSX. -George Add back trace support for other platforms -- Key: TS-127 URL: https://issues.apache.org/jira/browse/TS-127 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Environment: FreeBSD, OSX, OpenSolaris Reporter: George Paul Assignee: George Paul Fix For: 2.1.0 Back trace support similar to gdb backtrace() support should be added for FreeBSD, OSX and OpenSolaris in addition to the current Linux support. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-127) Add back trace support for other platforms
[ https://issues.apache.org/jira/browse/TS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845637#action_12845637 ] George Paul commented on TS-127: Add backtrace() support on OpenSolaris(osol0906) w/ GCC. -George Add back trace support for other platforms -- Key: TS-127 URL: https://issues.apache.org/jira/browse/TS-127 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Environment: FreeBSD, OSX, OpenSolaris Reporter: George Paul Assignee: George Paul Fix For: 2.1.0 Back trace support similar to gdb backtrace() support should be added for FreeBSD, OSX and OpenSolaris in addition to the current Linux support. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-244) FreeBSD needs -lexecinfo ?
[ https://issues.apache.org/jira/browse/TS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-244. Resolution: Fixed Fix Version/s: 2.1.0 FreeBSD needs -lexecinfo ? -- Key: TS-244 URL: https://issues.apache.org/jira/browse/TS-244 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Assignee: George Paul Priority: Minor Fix For: 2.1.0 It seems on FBSD (v8 at least), that you need to link in libexecinfo (so, -lexecinfo) in order to get the backtrace_symbols_fd() symbol. This probably needs to be associated with the check for the existance of execinfo.h. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-222) Cache::open_write should use an options arg for flexability and shoudl allow SYNC writes
[ https://issues.apache.org/jira/browse/TS-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-222: --- Fix Version/s: 2.1.0 Cache::open_write should use an options arg for flexability and shoudl allow SYNC writes Key: TS-222 URL: https://issues.apache.org/jira/browse/TS-222 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.0 Reporter: John Plevyak Assignee: John Plevyak Fix For: 2.1.0 Attachments: ts-222-jp-v1.patch Unix file open supports a number of options, e.g. O_DIRECT O_NOATIME etc. Currently open_write takes one option overwrite, but there are several other options which would be nice, including CLOSE_COMPLETE (finalize the object when nbytes == ndone and expect a close, preventing the head from being split from the data in cases where the object is small) and SYNC which would call COMPLETE when the object has hit the disk and would be recovered in the case of a crash. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-226) OpenSolaris: Need to provide/port atomic ops with Sun Studio compiler suite
[ https://issues.apache.org/jira/browse/TS-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul reassigned TS-226: -- Assignee: John Plevyak Okay reviewed and tested 'ts-226-atomic-jp-v1.patch' with Sun Studio CC and GCC 4.3.2. Looks good to commit. -George OpenSolaris: Need to provide/port atomic ops with Sun Studio compiler suite --- Key: TS-226 URL: https://issues.apache.org/jira/browse/TS-226 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.1.0 Environment: OpenSolaris w/ Sun Studio Compiler suite. Reporter: George Paul Assignee: John Plevyak Fix For: 2.1.0 Attachments: ts-226-atomic-jp-v1.patch Currently when using GNU compiler suite the GCC builtin atomic operations are used. For other compilers without such support we need to provide/port the required necessary atomic operations. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-225) Startup script not working on RHEL
[ https://issues.apache.org/jira/browse/TS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840212#action_12840212 ] George Paul commented on TS-225: Both patches 'redhat.diff' and 'debian.diff' look fine but need to be tested. Unfortunately I don't have either platform readily available. -George Startup script not working on RHEL -- Key: TS-225 URL: https://issues.apache.org/jira/browse/TS-225 Project: Traffic Server Issue Type: Bug Affects Versions: 2.0.0a Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Minor Fix For: 2.0.0 Attachments: debian.diff, redhat.diff On RHEL, trying to start with the init script, i get r...@stoodopen 8/0 # ./ats/bin/trafficserver start This script needs to be ported to this OS r...@stoodopen 9/0 # -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-226) OpenSolaris: Need to provide/port atomic ops with Sun Studio compiler suite
OpenSolaris: Need to provide/port atomic ops with Sun Studio compiler suite --- Key: TS-226 URL: https://issues.apache.org/jira/browse/TS-226 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.1.0 Environment: OpenSolaris w/ Sun Studio Compiler suite. Reporter: George Paul Fix For: 2.1.0 Currently when using GNU compiler suite the GCC builtin atomic operations are used. For other compilers without such support we need to provide/port the required necessary atomic operations. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-125) Cannot use user-defined types in typedef of template function
[ https://issues.apache.org/jira/browse/TS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-125: --- Attachment: 0001-TS125_offsetof_jp_v2.diff.patch Update jplevyak's original patch with '0001-TS125_offsetof_jp_v2.diff.patch' for more fixes with the Sun Studio compiler suite. Retested on OSX(10.5), Linux(Ubuntu904) and FreeBSD(7.2). The one(?) remaining issue on OpenSolaris w/ Sun Studio is that the atomic operations need to be provided/ported to 64 bit. Jira Ticket TS-226 has been opened for this. Please review, -George Cannot use user-defined types in typedef of template function - Key: TS-125 URL: https://issues.apache.org/jira/browse/TS-125 Project: Traffic Server Issue Type: Bug Components: Portability Environment: OpenSolaris with SunStudio (gcc on opensolaris fails the same code with a different error; same workaround fixes it) Reporter: Nick Kew Priority: Critical Attachments: 0001-TS125_offsetof_jp_v2.diff.patch, ts-125-offsetof-jp-v1.patch This appears to be related to Sun bug http://bugs.sun.com/view_bug.do?bug_id=6906118 but is sufficiently different that the workaround suggested there doesn't apply. Compiling DAllocator.h produces the following fatal error: DAllocator.h, line 86: Error: Unexpected type name AllocPoolDescriptor encountered. DAllocator.h, line 87: Error: Unexpected type name AllocDescriptor encountered. It can be worked around by reverting: @@ -83,8 +83,8 @@ int alignment; int el_size; - SList(AllocPoolDescriptor,link) pools; - Que(AllocDescriptor,link) free_list; + SLLAllocPoolDescriptor pools; + QueueAllocDescriptor free_list; Expanding that with the -E option to CC reveals that this loses an offsetof argument, so if we could fix the offset to zero then the problem goes away. If at all possible, it would be good to make link the first element of AllocDescriptor and AllocPoolDescriptor so the need for offsetof goes away. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-125) Cannot use user-defined types in typedef of template function
[ https://issues.apache.org/jira/browse/TS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul reassigned TS-125: -- Assignee: John Plevyak Cannot use user-defined types in typedef of template function - Key: TS-125 URL: https://issues.apache.org/jira/browse/TS-125 Project: Traffic Server Issue Type: Bug Components: Portability Affects Versions: 2.1.0 Environment: OpenSolaris with SunStudio (gcc on opensolaris fails the same code with a different error; same workaround fixes it) Reporter: Nick Kew Assignee: John Plevyak Priority: Critical Fix For: 2.1.0 Attachments: 0001-TS125_offsetof_jp_v2.diff.patch, ts-125-offsetof-jp-v1.patch This appears to be related to Sun bug http://bugs.sun.com/view_bug.do?bug_id=6906118 but is sufficiently different that the workaround suggested there doesn't apply. Compiling DAllocator.h produces the following fatal error: DAllocator.h, line 86: Error: Unexpected type name AllocPoolDescriptor encountered. DAllocator.h, line 87: Error: Unexpected type name AllocDescriptor encountered. It can be worked around by reverting: @@ -83,8 +83,8 @@ int alignment; int el_size; - SList(AllocPoolDescriptor,link) pools; - Que(AllocDescriptor,link) free_list; + SLLAllocPoolDescriptor pools; + QueueAllocDescriptor free_list; Expanding that with the -E option to CC reveals that this loses an offsetof argument, so if we could fix the offset to zero then the problem goes away. If at all possible, it would be good to make link the first element of AllocDescriptor and AllocPoolDescriptor so the need for offsetof goes away. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-125) Cannot use user-defined types in typedef of template function
[ https://issues.apache.org/jira/browse/TS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-125: --- Affects Version/s: 2.1.0 Fix Version/s: 2.1.0 Cannot use user-defined types in typedef of template function - Key: TS-125 URL: https://issues.apache.org/jira/browse/TS-125 Project: Traffic Server Issue Type: Bug Components: Portability Affects Versions: 2.1.0 Environment: OpenSolaris with SunStudio (gcc on opensolaris fails the same code with a different error; same workaround fixes it) Reporter: Nick Kew Assignee: John Plevyak Priority: Critical Fix For: 2.1.0 Attachments: 0001-TS125_offsetof_jp_v2.diff.patch, ts-125-offsetof-jp-v1.patch This appears to be related to Sun bug http://bugs.sun.com/view_bug.do?bug_id=6906118 but is sufficiently different that the workaround suggested there doesn't apply. Compiling DAllocator.h produces the following fatal error: DAllocator.h, line 86: Error: Unexpected type name AllocPoolDescriptor encountered. DAllocator.h, line 87: Error: Unexpected type name AllocDescriptor encountered. It can be worked around by reverting: @@ -83,8 +83,8 @@ int alignment; int el_size; - SList(AllocPoolDescriptor,link) pools; - Que(AllocDescriptor,link) free_list; + SLLAllocPoolDescriptor pools; + QueueAllocDescriptor free_list; Expanding that with the -E option to CC reveals that this loses an offsetof argument, so if we could fix the offset to zero then the problem goes away. If at all possible, it would be good to make link the first element of AllocDescriptor and AllocPoolDescriptor so the need for offsetof goes away. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-125) Cannot use user-defined types in typedef of template function
[ https://issues.apache.org/jira/browse/TS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-125. Resolution: Fixed Cannot use user-defined types in typedef of template function - Key: TS-125 URL: https://issues.apache.org/jira/browse/TS-125 Project: Traffic Server Issue Type: Bug Components: Portability Affects Versions: 2.1.0 Environment: OpenSolaris with SunStudio (gcc on opensolaris fails the same code with a different error; same workaround fixes it) Reporter: Nick Kew Assignee: John Plevyak Priority: Critical Fix For: 2.1.0 Attachments: 0001-TS125_offsetof_jp_v2.diff.patch, ts-125-offsetof-jp-v1.patch This appears to be related to Sun bug http://bugs.sun.com/view_bug.do?bug_id=6906118 but is sufficiently different that the workaround suggested there doesn't apply. Compiling DAllocator.h produces the following fatal error: DAllocator.h, line 86: Error: Unexpected type name AllocPoolDescriptor encountered. DAllocator.h, line 87: Error: Unexpected type name AllocDescriptor encountered. It can be worked around by reverting: @@ -83,8 +83,8 @@ int alignment; int el_size; - SList(AllocPoolDescriptor,link) pools; - Que(AllocDescriptor,link) free_list; + SLLAllocPoolDescriptor pools; + QueueAllocDescriptor free_list; Expanding that with the -E option to CC reveals that this loses an offsetof argument, so if we could fix the offset to zero then the problem goes away. If at all possible, it would be good to make link the first element of AllocDescriptor and AllocPoolDescriptor so the need for offsetof goes away. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Please check the 2.0.0-alpha release candidates
Hi all, Tested alpha candidate http://people.apache.org/~zwoop/ on Ubuntu-804(x86_64), +1 Ubuntu-904(x86_64), +1 Fedora-11(x86_64), +1 Checksums(md5,sha1) and GPG signature, +1 -George On 2/27/10 3:17 PM, Leif Hedstrom wrote: Hi all, before I send out for a [vote] to release 2.0.0-alpha to the PPMC, please check it out, and make sure it looks alright: http://people.apache.org/~zwoop/ Note that this release only supports Linux, but it'd be a good test to make sure it runs on as many linux distros as possible. Also, make sure the checksums and the GPG signature validates properly. Unless I hear otherwise, I will send out for a [vote] on this on Monday. Thanks! -- Leif
[jira] Commented: (TS-200) Package improvements for 2.0.0-alpha package release
[ https://issues.apache.org/jira/browse/TS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839824#action_12839824 ] George Paul commented on TS-200: This 'tar-ball.diff' looks good. -George Package improvements for 2.0.0-alpha package release Key: TS-200 URL: https://issues.apache.org/jira/browse/TS-200 Project: Traffic Server Issue Type: Improvement Affects Versions: 2.0.0a Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Blocker Fix For: 2.0.0a Attachments: tar-ball.diff This is a placeholder for all package issues preventing us from making an official ATS package relase. Please add comments as necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [vote] RTC vs CTR
+1 [X] CTR for trunk, RTC for all release branches. -George On 3/1/10 7:47 PM, Leif Hedstrom wrote: On 03/01/2010 08:44 PM, Leif Hedstrom wrote: [ ] RTC for everything except trivial changes (e.g. comments). [ ] RTC for everything, except very small changes which are CTR. [ ] RTC for everything, except code which would take ~5 minutes to review. Such changes are CTR. [X] CTR for trunk, RTC for all release branches. -- Leif
[jira] Commented: (TS-199) Startup script should fail on multiple invocations of start (or stop)
[ https://issues.apache.org/jira/browse/TS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12839273#action_12839273 ] George Paul commented on TS-199: AFAIK init.d/rc scripts ( 'rc/trafficserver') do not return an error on subsequent invocations but a status e.g. OK. For example the 'sshd' init.d script on Ubuntu: sudo /etc/init.d/ssh start * Starting OpenBSD Secure Shell server sshd [ OK ] sudo /etc/init.d/ssh start * Starting OpenBSD Secure Shell server sshd [ OK ] and sudo /etc/init.d/ssh stop * Stopping OpenBSD Secure Shell server sshd [ OK ] sudo /etc/init.d/ssh stop * Stopping OpenBSD Secure Shell server sshd [ OK ] -G Startup script should fail on multiple invocations of start (or stop) --- Key: TS-199 URL: https://issues.apache.org/jira/browse/TS-199 Project: Traffic Server Issue Type: Improvement Components: Packaging Reporter: Leif Hedstrom Priority: Minor Attachments: TS-199-v2-JasonGiedymin.patch, TS-199-v3-JasonGiedymin.patch, TS-199_r1.patch If I do # /etc/init.d/trafficserver start # /etc/init.d/trafficserver start I'd expect the second invocation to give an error, [NO]. Same thing with stop, if I run stop multiple times, if there are no process(es) to stop, each invocation ought to generate errors as well, e.g. r...@loki 507/0 # ./local/bin/trafficserver stop Stopping : [ OK ] Stopping : [ OK ] Stopping : [ OK ] r...@loki 508/0 # ./local/bin/trafficserver stop Stopping : [ NOT ] Stopping : [ NOT ] Stopping : [ NOT ] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-204) not able to get stats from traffic_line
[ https://issues.apache.org/jira/browse/TS-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838522#action_12838522 ] George Paul commented on TS-204: I think it would be more consistent to stay with 'ink_snprintf' and move away from internal implementations during cleanup phase, otherwise confusion/bugs will be the norm as internal code paths expect the internal usage/behavior. -G not able to get stats from traffic_line --- Key: TS-204 URL: https://issues.apache.org/jira/browse/TS-204 Project: Traffic Server Issue Type: Bug Environment: Fedora 12 x86_64 Reporter: Bryan Call Assignee: Bryan Call Fix For: 2.0.0a Attachments: ink_sprintf_bcall_001.diff Stats are showing up as NULL values from traffic_line: /usr/local/bin/traffic_line -r proxy.node.http.user_agent_current_connections_count NULL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-204) not able to get stats from traffic_line
[ https://issues.apache.org/jira/browse/TS-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838534#action_12838534 ] George Paul commented on TS-204: One last thing, since 'ink_sprintf' is broken(?) can we fence it off(#ifdef ?)/mark it for removal in the code i.e. indicate that is deprecated for removal. Just in case somone see's the fcn and tries to use not knowing it is broken. Also if you think there are other fcns that are broken we should probably do something similar also. thanks, -Geprge not able to get stats from traffic_line --- Key: TS-204 URL: https://issues.apache.org/jira/browse/TS-204 Project: Traffic Server Issue Type: Bug Environment: Fedora 12 x86_64 Reporter: Bryan Call Assignee: Bryan Call Fix For: 2.0.0a Attachments: ink_sprintf_bcall_001.diff, ink_sprintf_bcall_002.diff Stats are showing up as NULL values from traffic_line: /usr/local/bin/traffic_line -r proxy.node.http.user_agent_current_connections_count NULL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-204) not able to get stats from traffic_line
[ https://issues.apache.org/jira/browse/TS-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838543#action_12838543 ] George Paul commented on TS-204: Patch 'ink_sprintf_bcall_003.diff' reviewed and tested under load. +1 -George not able to get stats from traffic_line --- Key: TS-204 URL: https://issues.apache.org/jira/browse/TS-204 Project: Traffic Server Issue Type: Bug Environment: Fedora 12 x86_64 Reporter: Bryan Call Assignee: Bryan Call Fix For: 2.0.0a Attachments: ink_sprintf_bcall_001.diff, ink_sprintf_bcall_002.diff, ink_sprintf_bcall_003.diff Stats are showing up as NULL values from traffic_line: /usr/local/bin/traffic_line -r proxy.node.http.user_agent_current_connections_count NULL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Branch 2.0.x has been created (trunk is back open)
Hi Everyone, Trunk is open again. Done with the merge of 'dev' back into 'trunk'. Please let me/John know if there are any issues with this merge. thanks, -George On 2/24/10 8:01 AM, Leif Hedstrom wrote: On 02/24/2010 08:58 AM, George Paul wrote: Hi Everyone, I am starting the merge of 'dev' branch back onto 'trunk' today and hope to be done by EOD if not sooner. If possible I would like to 'close' trunk down for that period. Please let me know if that will cause any issues. +1, keep it closed as long as you need. -- Leif
[jira] Resolved: (TS-50) FreeBSD support
[ https://issues.apache.org/jira/browse/TS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-50. --- Resolution: Fixed Pulled current remaining 2 issues into TS-207 and TS-211. -George FreeBSD support --- Key: TS-50 URL: https://issues.apache.org/jira/browse/TS-50 Project: Traffic Server Issue Type: Improvement Components: Portability Reporter: Paul Querna Assignee: George Paul Fix For: 2.1.0 Attachments: TS50_patch2.diff, TS50_tcl_patch3.diff, TS50_tm_tc_patch4.diff placeholder for freebsd porting related commits -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-11) Solaris port
[ https://issues.apache.org/jira/browse/TS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-11. --- Resolution: Fixed Pulled current remaining 2 issues into TS-209 and TS-212. -George Solaris port Key: TS-11 URL: https://issues.apache.org/jira/browse/TS-11 Project: Traffic Server Issue Type: Improvement Components: Portability Reporter: Bryan Call Assignee: George Paul Priority: Minor Fix For: 2.1.0 Attachments: 0001-bcall-solaris_updates.patch, 0002-bcall-solaris_updates.patch, ts.sol.diff, TS11_osol_patch1.diff Theo is going to supply patches for a Solaris port -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-213) Rename 'install' directory to 'rc'
[ https://issues.apache.org/jira/browse/TS-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-213. Resolution: Fixed Fixed in trunk and 2.0.x branch -George Rename 'install' directory to 'rc' -- Key: TS-213 URL: https://issues.apache.org/jira/browse/TS-213 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 2.0.0 Environment: All Reporter: George Paul Assignee: George Paul Priority: Minor Fix For: 2.0.0 Rename 'install' dir to 'rc' to avoid issues on case insensitive OSX HFS file-systems. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-206) libev license
[ https://issues.apache.org/jira/browse/TS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838180#action_12838180 ] George Paul commented on TS-206: Discussed with John, I think we can remove libev out the source repo and put in README-libev the procedure on how to get it to compile for ATS and any patches necessary to get it work on a certain platform. -George libev license - Key: TS-206 URL: https://issues.apache.org/jira/browse/TS-206 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Assignee: John Plevyak Fix For: 2.1.0 We need to include the AL2 license blurb in the libev files, and make sure that the NOTICE and LICENSE files are properly up-to-date with the BSD inclusions. I believe the general recommendation is to attach the AL2 license to the libev files, since the whole purpose of including this source is for our own modifications to the source, and those modifications should be covered by AL2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-202) make install should install config files as the same user as runtime will write them back as
[ https://issues.apache.org/jira/browse/TS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-202: --- Attachment: 0001-TS202_patch1.diff.patch This patch '0001-TS202_patch1.diff.patch' fixes the ownership permissions for the config files, etc. -George make install should install config files as the same user as runtime will write them back as -- Key: TS-202 URL: https://issues.apache.org/jira/browse/TS-202 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Assignee: George Paul Priority: Minor Fix For: 2.0.0a Attachments: 0001-TS202_patch1.diff.patch When doing a make install, it's confusing that the ownership of the config files are root, while after running, they get rewritten as the runtime user (nobody by default). We should make sure install sets the owner properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-202) make install should install config files as the same user as runtime will write them back as
[ https://issues.apache.org/jira/browse/TS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-202: --- Component/s: Build Affects Version/s: 2.0.0a make install should install config files as the same user as runtime will write them back as -- Key: TS-202 URL: https://issues.apache.org/jira/browse/TS-202 Project: Traffic Server Issue Type: Bug Components: Build Affects Versions: 2.0.0a Reporter: Leif Hedstrom Assignee: George Paul Priority: Minor Fix For: 2.0.0a Attachments: 0001-TS202_patch1.diff.patch When doing a make install, it's confusing that the ownership of the config files are root, while after running, they get rewritten as the runtime user (nobody by default). We should make sure install sets the owner properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-144) in P_EventSystem.h IOCORE_MachineFatal is currently #define to printf, that can't be right
[ https://issues.apache.org/jira/browse/TS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-144: --- Fix Version/s: (was: 2.0.0a) 2.1.0 in P_EventSystem.h IOCORE_MachineFatal is currently #define to printf, that can't be right -- Key: TS-144 URL: https://issues.apache.org/jira/browse/TS-144 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.1.0 Reporter: John Plevyak Fix For: 2.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-164) 1)reducing timeout to 1ms; 2)using pipe fd as signal between netthreads
[ https://issues.apache.org/jira/browse/TS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-164: --- Attachment: TS164_patch2.diff A closer code review of original patch showed incorrect handling of EVENTFD type case in mainNetEvent handler (copy paste error? ). This patch 'TS164_patch2.diff' fixes this and is a replacement for the original patch 'TS-164.patch' . Tested in forward proxy mode and no longer see TS 'hung' state. -George 1)reducing timeout to 1ms; 2)using pipe fd as signal between netthreads --- Key: TS-164 URL: https://issues.apache.org/jira/browse/TS-164 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Wendy Huang Assignee: Leif Hedstrom Fix For: 2.0.0a Attachments: TS-164.patch, TS164_patch2.diff This is copied from bugzilla 3095908. two type of changes made in this bug as indicated in summary. Need to merge the change to open source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-144) in P_EventSystem.h IOCORE_MachineFatal is currently #define to printf, that can't be right
[ https://issues.apache.org/jira/browse/TS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-144: --- Component/s: Core Affects Version/s: 2.1.0 Fix Version/s: 2.0.0a in P_EventSystem.h IOCORE_MachineFatal is currently #define to printf, that can't be right -- Key: TS-144 URL: https://issues.apache.org/jira/browse/TS-144 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.1.0 Reporter: John Plevyak Fix For: 2.0.0a -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-164) 1)reducing timeout to 1ms; 2)using pipe fd as signal between netthreads
[ https://issues.apache.org/jira/browse/TS-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-164: --- Component/s: Core 1)reducing timeout to 1ms; 2)using pipe fd as signal between netthreads --- Key: TS-164 URL: https://issues.apache.org/jira/browse/TS-164 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Wendy Huang Assignee: Leif Hedstrom Fix For: 2.0.0a Attachments: TS-164.patch This is copied from bugzilla 3095908. two type of changes made in this bug as indicated in summary. Need to merge the change to open source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-197) Stats: Properly initialize the Stats coupled and floating point mutexes
Stats: Properly initialize the Stats coupled and floating point mutexes --- Key: TS-197 URL: https://issues.apache.org/jira/browse/TS-197 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Fix For: 2.0.0a The Stats coupled and floating point mutexes are not properly initialized during startup. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-197) Stats: Properly initialize the Stats coupled and floating point mutexes
[ https://issues.apache.org/jira/browse/TS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-197: --- Attachment: TS197_patch1.diff Stats: Properly initialize the Stats coupled and floating point mutexes --- Key: TS-197 URL: https://issues.apache.org/jira/browse/TS-197 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Fix For: 2.0.0a Attachments: TS197_patch1.diff The Stats coupled and floating point mutexes are not properly initialized during startup. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-197) Stats: Properly initialize the Stats coupled and floating point mutexes if using SDK API/plugins
[ https://issues.apache.org/jira/browse/TS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-197: --- Description: The Stats coupled and floating point mutexes are not properly initialized during startup if using the SDK API/plugins. -George was: The Stats coupled and floating point mutexes are not properly initialized during startup. -George Summary: Stats: Properly initialize the Stats coupled and floating point mutexes if using SDK API/plugins (was: Stats: Properly initialize the Stats coupled and floating point mutexes) Stats: Properly initialize the Stats coupled and floating point mutexes if using SDK API/plugins Key: TS-197 URL: https://issues.apache.org/jira/browse/TS-197 Project: Traffic Server Issue Type: Bug Components: Stats Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Fix For: 2.0.0a Attachments: TS197_patch1.diff The Stats coupled and floating point mutexes are not properly initialized during startup if using the SDK API/plugins. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-198) Buffer overrun case in SDK API Regression Test synthetic client server
Buffer overrun case in SDK API Regression Test synthetic client server Key: TS-198 URL: https://issues.apache.org/jira/browse/TS-198 Project: Traffic Server Issue Type: Bug Components: InkAPI Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Fix For: 2.0.0a Buffer overrun case in SDK API Regression Test synthetic client server -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (TS-198) Buffer overrun case in SDK API Regression Test synthetic client server
[ https://issues.apache.org/jira/browse/TS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-198 started by George Paul. Buffer overrun case in SDK API Regression Test synthetic client server Key: TS-198 URL: https://issues.apache.org/jira/browse/TS-198 Project: Traffic Server Issue Type: Bug Components: InkAPI Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Fix For: 2.0.0a Buffer overrun case in SDK API Regression Test synthetic client server -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-198) Buffer overrun case in SDK API Regression Test synthetic client server
[ https://issues.apache.org/jira/browse/TS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-198: --- Attachment: TS198_patch1.diff This patch 'TS198_patch1.diff' fiesx buffer overrun case in SDK API Regression Test synthetic client server when reading responses and requests. -George Buffer overrun case in SDK API Regression Test synthetic client server Key: TS-198 URL: https://issues.apache.org/jira/browse/TS-198 Project: Traffic Server Issue Type: Bug Components: InkAPI Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Fix For: 2.0.0a Attachments: TS198_patch1.diff Buffer overrun case in SDK API Regression Test synthetic client server -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-9) InkAPI.h and RemapPlugin.h are missing from /usr/local/include
[ https://issues.apache.org/jira/browse/TS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835278#action_12835278 ] George Paul commented on TS-9: -- The ' TS-9-Remap_h.patch' patch looks fine. Reviewed and tested. -George InkAPI.h and RemapPlugin.h are missing from /usr/local/include --- Key: TS-9 URL: https://issues.apache.org/jira/browse/TS-9 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.0.0a Attachments: TS-9-InkAPI-h.patch, TS-9-Remap_h.patch I think we need to install (gmake install) these two files into $PREFIX/include. This is to make building plugins easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-9) InkAPI.h and RemapPlugin.h are missing from /usr/local/include
[ https://issues.apache.org/jira/browse/TS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835530#action_12835530 ] George Paul commented on TS-9: -- Changes look fine. After applying the patch I had to edit the moved/copied over 'InkAPIPrivate.h' - 'ts_private.h' and change InkAPIPrivateFrozen.h - 'ts_private_frozen.h. Reviewed and tested. -George InkAPI.h and RemapPlugin.h are missing from /usr/local/include --- Key: TS-9 URL: https://issues.apache.org/jira/browse/TS-9 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.0.0a Attachments: TS-9-InkAPI-h.patch, TS-9-Private_h.patch, TS-9-Remap_h.patch I think we need to install (gmake install) these two files into $PREFIX/include. This is to make building plugins easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-9) InkAPI.h and RemapPlugin.h are missing from /usr/local/include
[ https://issues.apache.org/jira/browse/TS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835573#action_12835573 ] George Paul commented on TS-9: -- Patch 'TS-9-Makefile.patch' looks fine. Reviewed and tested. -George InkAPI.h and RemapPlugin.h are missing from /usr/local/include --- Key: TS-9 URL: https://issues.apache.org/jira/browse/TS-9 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.0.0a Attachments: TS-9-InkAPI-h.patch, TS-9-Makefile.patch, TS-9-Private_h.patch, TS-9-Remap_h.patch I think we need to install (gmake install) these two files into $PREFIX/include. This is to make building plugins easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-167) Support InkHttpFetchPage(s) in the TS API
[ https://issues.apache.org/jira/browse/TS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834904#action_12834904 ] George Paul commented on TS-167: If possible it would be nice if a Regression test for this new INK API call could be added to 'proxy/InkAPITest.cc'. -George Support InkHttpFetchPage(s) in the TS API - Key: TS-167 URL: https://issues.apache.org/jira/browse/TS-167 Project: Traffic Server Issue Type: New Feature Components: InkAPI Reporter: Sean Cosgrave Attachments: FetchSM.cc, FetchSM.h, fp_fetch_diff.txt This is the original description from Anirban: There are quite a few people that are attempting to write plugins that download data from an origin server (or other HTTP sites) and then optionally modify the contents like the transformation plugins allow for. However, the downloading of the pages is cumbersome and a repeated task as this, should be wrapped in an API. The input into the function would be 1. provide the headers passed into YTS as part of the request - the header should obviously include the url to fetch 2. provide the moment when to wake up the plugin's continuation. Options include 0 - as soon as the request is made - no attempt is made to wait for the download to happen 1 - as soon as the headers are downloaded 2 - as soon as a portion of the message is downloaded 3 - after the full download is complete 3. ability to not cache the data (optional) (only used if one would like to override the data 4. ability to not run plugins (optional) The output of the function would be 1. for each of the results - error codes that define the download status of each of the requests - IOBuffer ptr (or char*) to the results (the caller of the fxn has to release references to the IOBuffers or if char* is used free the chunk) - time to download each object (not so critical) Note: This fxn doesnt support streaming the answer back to the requesting client. The fetches should be asynchronous and simultaneous. A possible model would be to have the user call INKHttpFetchPages which then in turn calls INKHttpFetchPage per request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-9) InkAPI.h and RemapPlugin.h are missing from /usr/local/include
[ https://issues.apache.org/jira/browse/TS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12835094#action_12835094 ] George Paul commented on TS-9: -- Apply the patch seems to not delete the old 'InkAPI.h' and create the new 'ts.h'. Other than that it looks fine after changing 'InkAPI.h' - 'ts.h' and fixing it's header #define -George InkAPI.h and RemapPlugin.h are missing from /usr/local/include --- Key: TS-9 URL: https://issues.apache.org/jira/browse/TS-9 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.0.0a Attachments: TS-9-InkAPI-h.patch I think we need to install (gmake install) these two files into $PREFIX/include. This is to make building plugins easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (TS-183) Disable RAF and Overseer ports by default
[ https://issues.apache.org/jira/browse/TS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-183 started by George Paul. Disable RAF and Overseer ports by default - Key: TS-183 URL: https://issues.apache.org/jira/browse/TS-183 Project: Traffic Server Issue Type: Bug Components: Config Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Priority: Minor Fix For: 2.0.0a Disable RAF and Overseer ports by default. The RAF code needs to be removed during cleanup in a future release. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-183) Disable RAF and Overseer ports by default
Disable RAF and Overseer ports by default - Key: TS-183 URL: https://issues.apache.org/jira/browse/TS-183 Project: Traffic Server Issue Type: Bug Components: Config Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Priority: Minor Fix For: 2.0.0a Disable RAF and Overseer ports by default. The RAF code needs to be removed during cleanup in a future release. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-183) Disable RAF and Overseer ports by default
[ https://issues.apache.org/jira/browse/TS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-183: --- Attachment: 0001-TS183_patch1.diff.patch This patch '0001-TS183_patch1.diff.patch' disables the RAF and Overseer ports by default. Also sets the default ports in TC to be same as in TM and TS. -George Disable RAF and Overseer ports by default - Key: TS-183 URL: https://issues.apache.org/jira/browse/TS-183 Project: Traffic Server Issue Type: Bug Components: Config Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Priority: Minor Fix For: 2.0.0a Attachments: 0001-TS183_patch1.diff.patch Disable RAF and Overseer ports by default. The RAF code needs to be removed during cleanup in a future release. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (TS-2) OSX port
[ https://issues.apache.org/jira/browse/TS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-2 started by George Paul. OSX port Key: TS-2 URL: https://issues.apache.org/jira/browse/TS-2 Project: Traffic Server Issue Type: Improvement Components: Portability Affects Versions: 2.0.0a Reporter: Leif Hedstrom Assignee: George Paul Priority: Minor Fix For: 2.1.0 Attachments: fix_traffic_manager_running_on_osx.patch, fix_traffic_server_fd_bug_on_osx.patch, libinktomi_tests_working_osx.patch, os_detection.diff, osx-etc.patch, TS2_patch2.diff, TS2_patch3.diff, vmap_fix_paths_on_osx.patch Placeholder for all checkins related to the OSX port. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-2) OSX port
[ https://issues.apache.org/jira/browse/TS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834357#action_12834357 ] George Paul commented on TS-2: -- Geoff G. os_detection.diff patch has been committed to 'dev' branch. The current recommendation on OSX(10.5) is to use the GCC 4.2.4 compiler suite (available via ports) Please let me know if you have other OSXs compilers working. The Berkeley DB is no longer a build requirement but sqlite3(= 3.5) is. Also currently only a file cache is supported. Raw disk support will be added later. After setting the cluster interface in 'records.config'. e.g. CONFIG proxy.config.cluster.ethernet_interface STRING en0 Traffic Sever process stack can be started via sudo /usr/local/bin/traffic_cop since there currently is no OSX support in the 'trafficserver' script. -George OSX port Key: TS-2 URL: https://issues.apache.org/jira/browse/TS-2 Project: Traffic Server Issue Type: Improvement Components: Portability Affects Versions: 2.0.0a Reporter: Leif Hedstrom Assignee: George Paul Priority: Minor Fix For: 2.1.0 Attachments: fix_traffic_manager_running_on_osx.patch, fix_traffic_server_fd_bug_on_osx.patch, libinktomi_tests_working_osx.patch, os_detection.diff, osx-etc.patch, TS2_patch2.diff, TS2_patch3.diff, vmap_fix_paths_on_osx.patch Placeholder for all checkins related to the OSX port. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (TS-50) FreeBSD support
[ https://issues.apache.org/jira/browse/TS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-50 started by George Paul. FreeBSD support --- Key: TS-50 URL: https://issues.apache.org/jira/browse/TS-50 Project: Traffic Server Issue Type: Improvement Components: Portability Reporter: Paul Querna Assignee: George Paul Fix For: 2.1.0 Attachments: TS50_patch2.diff, TS50_tcl_patch3.diff, TS50_tm_tc_patch4.diff placeholder for freebsd porting related commits -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (TS-127) Add back trace support for other platforms
[ https://issues.apache.org/jira/browse/TS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-127 started by George Paul. Add back trace support for other platforms -- Key: TS-127 URL: https://issues.apache.org/jira/browse/TS-127 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Environment: FreeBSD, OSX, OpenSolaris Reporter: George Paul Assignee: George Paul Fix For: 2.1.0 Back trace support similar to gdb backtrace() support should be added for FreeBSD, OSX and OpenSolaris in addition to the current Linux support. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-183) Disable RAF and Overseer ports by default
[ https://issues.apache.org/jira/browse/TS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-183. Resolution: Fixed Disable RAF and Overseer ports by default - Key: TS-183 URL: https://issues.apache.org/jira/browse/TS-183 Project: Traffic Server Issue Type: Bug Components: Config Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Priority: Minor Fix For: 2.0.0a Attachments: 0001-TS183_patch1.diff.patch Disable RAF and Overseer ports by default. The RAF code needs to be removed during cleanup in a future release. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-91) Traffic Manager WebUI disabled
[
https://issues.apache.org/jira/browse/TS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-91:
--
Fix Version/s: 2.1.0
Summary: Traffic Manager WebUI disabled (was: Traffic Manager starts
up with WebUI disabled)
Traffic Manager WebUI disabled
--
Key: TS-91
URL: https://issues.apache.org/jira/browse/TS-91
Project: Traffic Server
Issue Type: Bug
Components: WebUI
Affects Versions: 2.0.0a
Environment: All
Reporter: George Paul
Fix For: 2.1.0
With issue TS-6 closed Traffic Manager comes up with the Web UI disabled. The
output is similar to the following:
[Dec 15 20:16:24.732] Manager {3052399504} ERROR: [WebIntrMain] Web Interface
Intialization failed.
[Dec 15 20:16:24.732] Manager {3052399504} ERROR: (last system error 2: No
such file or directory)
[Dec 15 20:16:24.746] Manager {3052399504} ERROR: [WebHttpTreeInit]: unable
to import file /usr/local/share/trafficserver/navigation_tree.xml
[Dec 15 20:16:24.746] Manager {3052399504} ERROR: (last system error 2: No
such file or directory)
-George
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-91) Traffic Manager WebUI disabled
[
https://issues.apache.org/jira/browse/TS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12834549#action_12834549
]
George Paul commented on TS-91:
---
With the fix for TS-150 the default now is to disable the Web UI until it can
be worked on. The Web UI can be re-enabled at configure time via the configure
flag '--enable-webui'.
-George
Traffic Manager WebUI disabled
--
Key: TS-91
URL: https://issues.apache.org/jira/browse/TS-91
Project: Traffic Server
Issue Type: Bug
Components: WebUI
Affects Versions: 2.0.0a
Environment: All
Reporter: George Paul
Fix For: 2.1.0
With issue TS-6 closed Traffic Manager comes up with the Web UI disabled. The
output is similar to the following:
[Dec 15 20:16:24.732] Manager {3052399504} ERROR: [WebIntrMain] Web Interface
Intialization failed.
[Dec 15 20:16:24.732] Manager {3052399504} ERROR: (last system error 2: No
such file or directory)
[Dec 15 20:16:24.746] Manager {3052399504} ERROR: [WebHttpTreeInit]: unable
to import file /usr/local/share/trafficserver/navigation_tree.xml
[Dec 15 20:16:24.746] Manager {3052399504} ERROR: (last system error 2: No
such file or directory)
-George
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-150) Startup errors for TM admin GUI
[
https://issues.apache.org/jira/browse/TS-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul reassigned TS-150:
--
Assignee: George Paul
Startup errors for TM admin GUI
---
Key: TS-150
URL: https://issues.apache.org/jira/browse/TS-150
Project: Traffic Server
Issue Type: Bug
Components: WebUI
Reporter: Leif Hedstrom
Assignee: George Paul
Priority: Minor
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} NOTE:
[checkWebContext] Unable to access document root
'/usr/local/share/trafficserver' for Web Management : No such file or
directory
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR:
[WebIntrMain] Web Interface Intialization failed.
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR: (last
system error 2: No such file or directory)
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR:
[WebHttpTreeInit]: unable to import file
/usr/local/share/trafficserver/navigation_tree.xml
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR: (last
system error 2: No such file or directory)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-150) Startup errors for TM admin GUI
[
https://issues.apache.org/jira/browse/TS-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Paul updated TS-150:
---
Attachment: 0001-TS150_patch1.diff.patch
This patch '0001-TS150_patch1.diff.patch' fixes the startup errors from Traffic
Manager Web UI. Also the default now is to disable the Web UI until it can be
worked on. The Web UI can be re-enabled at configure time via the configure
flag '--enable-webui'.
-George
Startup errors for TM admin GUI
---
Key: TS-150
URL: https://issues.apache.org/jira/browse/TS-150
Project: Traffic Server
Issue Type: Bug
Components: WebUI
Reporter: Leif Hedstrom
Assignee: George Paul
Priority: Minor
Attachments: 0001-TS150_patch1.diff.patch
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} NOTE:
[checkWebContext] Unable to access document root
'/usr/local/share/trafficserver' for Web Management : No such file or
directory
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR:
[WebIntrMain] Web Interface Intialization failed.
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR: (last
system error 2: No such file or directory)
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR:
[WebHttpTreeInit]: unable to import file
/usr/local/share/trafficserver/navigation_tree.xml
Feb 8 09:51:16 loki traffic_manager[10064]: {3054136208} ERROR: (last
system error 2: No such file or directory)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-165) Config files (records.config at least) can get wrong ownership
[ https://issues.apache.org/jira/browse/TS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul reassigned TS-165: -- Assignee: George Paul (was: Leif Hedstrom) Config files (records.config at least) can get wrong ownership -- Key: TS-165 URL: https://issues.apache.org/jira/browse/TS-165 Project: Traffic Server Issue Type: Bug Components: Config Reporter: Leif Hedstrom Assignee: George Paul Priority: Critical Fix For: 2.0.0a With the following steps, I get records.config to become owned by root, when it should stay owned by nobody: (04:43:38 PM) zwoop: Ok, so this reproduces it every time on my fedora box, gonna try it on ubuntu next (04:44:41 PM) zwoop: This is what I did (04:44:41 PM) zwoop: 1) rm -rf local (04:44:41 PM) zwoop: 2) sudo gmake install (04:44:41 PM) zwoop: 3) emacs local/etc/trafficserver/records.config (04:44:41 PM) zwoop: change port from 8080 to 80, and change eth0 to eth1 (I have to do the later, or it'll fail) (04:44:41 PM) zwoop: 4) local/bin/trafficserver start (04:44:41 PM) zwoop: 5) Wait 10-20 seconds (at least, maybe longer) (04:44:41 PM) zwoop: 6) ls -lrt local/etc/trafficserver -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-165) Config files (records.config at least) can get wrong ownership
[ https://issues.apache.org/jira/browse/TS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-165: --- Attachment: 0001-TS165_patch1.diff.patch This patch '0001-TS165_patch1.diff.patch' fixes the problem of removing root privileges and restoring the original user. -George Config files (records.config at least) can get wrong ownership -- Key: TS-165 URL: https://issues.apache.org/jira/browse/TS-165 Project: Traffic Server Issue Type: Bug Components: Config Reporter: Leif Hedstrom Assignee: George Paul Priority: Critical Fix For: 2.0.0a Attachments: 0001-TS165_patch1.diff.patch With the following steps, I get records.config to become owned by root, when it should stay owned by nobody: (04:43:38 PM) zwoop: Ok, so this reproduces it every time on my fedora box, gonna try it on ubuntu next (04:44:41 PM) zwoop: This is what I did (04:44:41 PM) zwoop: 1) rm -rf local (04:44:41 PM) zwoop: 2) sudo gmake install (04:44:41 PM) zwoop: 3) emacs local/etc/trafficserver/records.config (04:44:41 PM) zwoop: change port from 8080 to 80, and change eth0 to eth1 (I have to do the later, or it'll fail) (04:44:41 PM) zwoop: 4) local/bin/trafficserver start (04:44:41 PM) zwoop: 5) Wait 10-20 seconds (at least, maybe longer) (04:44:41 PM) zwoop: 6) ls -lrt local/etc/trafficserver -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-165) Config files (records.config at least) can get wrong ownership
[ https://issues.apache.org/jira/browse/TS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul reassigned TS-165: -- Assignee: Leif Hedstrom (was: George Paul) Config files (records.config at least) can get wrong ownership -- Key: TS-165 URL: https://issues.apache.org/jira/browse/TS-165 Project: Traffic Server Issue Type: Bug Components: Config Reporter: Leif Hedstrom Assignee: Leif Hedstrom Priority: Critical Fix For: 2.0.0a Attachments: 0001-TS165_patch1.diff.patch With the following steps, I get records.config to become owned by root, when it should stay owned by nobody: (04:43:38 PM) zwoop: Ok, so this reproduces it every time on my fedora box, gonna try it on ubuntu next (04:44:41 PM) zwoop: This is what I did (04:44:41 PM) zwoop: 1) rm -rf local (04:44:41 PM) zwoop: 2) sudo gmake install (04:44:41 PM) zwoop: 3) emacs local/etc/trafficserver/records.config (04:44:41 PM) zwoop: change port from 8080 to 80, and change eth0 to eth1 (I have to do the later, or it'll fail) (04:44:41 PM) zwoop: 4) local/bin/trafficserver start (04:44:41 PM) zwoop: 5) Wait 10-20 seconds (at least, maybe longer) (04:44:41 PM) zwoop: 6) ls -lrt local/etc/trafficserver -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TS-126) Solaris build ink_queue fails on freelist definition
[ https://issues.apache.org/jira/browse/TS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul reassigned TS-126: -- Assignee: George Paul Solaris build ink_queue fails on freelist definition Key: TS-126 URL: https://issues.apache.org/jira/browse/TS-126 Project: Traffic Server Issue Type: Bug Components: Core Environment: OpenSolaris with Sun CC on AMD64 Reporter: Nick Kew Assignee: George Paul configure.ac contains the following line: common_opt=-mt -m32 -D__WORDSIZE=32 # FIXME: This should be detected This specifies 32-bit build, which fails with ink_queue.cc, line 136: Error: s is not a member of volatile head_p. (repeated many times). This is a define at line 74 of ink_queue.h. I'm struggling to follow the significance of all the #defines in this code, but there's evidently an inconsistency. It compiles just fine with common_opt=-mt -m64 -D__WORDSIZE=64 # FIXME: This should be detected though I have yet to run it in 64 bits! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-126) Solaris build ink_queue fails on freelist definition
[ https://issues.apache.org/jira/browse/TS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-126. Resolution: Fixed Solaris build ink_queue fails on freelist definition Key: TS-126 URL: https://issues.apache.org/jira/browse/TS-126 Project: Traffic Server Issue Type: Bug Components: Core Environment: OpenSolaris with Sun CC on AMD64 Reporter: Nick Kew Assignee: George Paul configure.ac contains the following line: common_opt=-mt -m32 -D__WORDSIZE=32 # FIXME: This should be detected This specifies 32-bit build, which fails with ink_queue.cc, line 136: Error: s is not a member of volatile head_p. (repeated many times). This is a define at line 74 of ink_queue.h. I'm struggling to follow the significance of all the #defines in this code, but there's evidently an inconsistency. It compiles just fine with common_opt=-mt -m64 -D__WORDSIZE=64 # FIXME: This should be detected though I have yet to run it in 64 bits! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-124) Solaris compile requires -D_POSIX_PTHREAD_SEMANTICS
[ https://issues.apache.org/jira/browse/TS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul resolved TS-124. Resolution: Fixed Solaris compile requires -D_POSIX_PTHREAD_SEMANTICS --- Key: TS-124 URL: https://issues.apache.org/jira/browse/TS-124 Project: Traffic Server Issue Type: Bug Components: Build Environment: Solaris with SunStudio Reporter: Nick Kew Assignee: George Paul Priority: Critical Fix For: 2.1.0 ctime_r has two different prototypes, with either two or three arguments. To get the compiler to recognise the two-argument form used in libinktomi++/InkTime.cc requires _POSIX_PTHREAD_SEMANTICS to be defined in the build. This can probably be harmlessly added to the Makefile across platforms. Googling found a useful explanation at http://www.openldap.org/lists/openldap-bugs/199812/msg00110.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-11) Solaris port
[ https://issues.apache.org/jira/browse/TS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12833628#action_12833628 ] George Paul commented on TS-11: --- Fixes for using Sun studio Compiler on 64-bit have been checked into 'dev' branch. Also incorporated changes from TS-124 and TS-126 (thanks to Nick Kew). Further progress with Sun studio compiler can not be made due to TS-125. The current recommendation on OpenSolaris is to use the GCC 4.3.2 compiler suite. Also Berkeley DB is no longer required so the configuration can be just: ../configure CC=/usr/bin/gcc-4.3.2 CXX=/usr/bin/g++-4.3.2 After setting the cluster interface in 'records.config'. e.g. CONFIG proxy.config.cluster.ethernet_interface STRING e1000g0 Traffic Sever process stack can be started via sudo /usr/local/bin/traffic_cop since currently there is no OpenSolaris support in the 'trafficserver' script. -George Solaris port Key: TS-11 URL: https://issues.apache.org/jira/browse/TS-11 Project: Traffic Server Issue Type: Improvement Components: Portability Reporter: Bryan Call Assignee: George Paul Priority: Minor Fix For: 2.1.0 Attachments: 0001-bcall-solaris_updates.patch, 0002-bcall-solaris_updates.patch, ts.sol.diff, TS11_osol_patch1.diff Theo is going to supply patches for a Solaris port -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-127) Add back trace support for other platforms
[ https://issues.apache.org/jira/browse/TS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-127: --- Fix Version/s: 2.1.0 Add back trace support for other platforms -- Key: TS-127 URL: https://issues.apache.org/jira/browse/TS-127 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Environment: FreeBSD, OSX, OpenSolaris Reporter: George Paul Assignee: George Paul Fix For: 2.1.0 Back trace support similar to gdb backtrace() support should be added for FreeBSD, OSX and OpenSolaris in addition to the current Linux support. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-84) code base: PATH_NAME_MAX vs PATH_MAX
[ https://issues.apache.org/jira/browse/TS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-84: -- Fix Version/s: 3.0 code base: PATH_NAME_MAX vs PATH_MAX Key: TS-84 URL: https://issues.apache.org/jira/browse/TS-84 Project: Traffic Server Issue Type: Improvement Components: Cleanup Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Priority: Minor Fix For: 3.0 Originally PATH_NAME_MAX was to be used for PATH_MAX for portability between OS's AFAIR. PATH_MAX is inconsistent on various OSs (linux-4096, osx/bsd-1024, windows-260(?), etc). TS is more consistent in the use of PATH_NAME_MAX in the code base (cache, hostdb, plugins, etc) while TM is not as consistent. TC never used it. The code base needs to examined for usage of both and made consistent and portable. The current suggestion is to use what TS currently uses which is PATH_NAME_MAX. This should be revisited when this issue is worked on. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-71) Cleanup MODULARIZED: Check the code base for remants of modularized #ifdef's in the code and configuration system.
[ https://issues.apache.org/jira/browse/TS-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Paul updated TS-71: -- Fix Version/s: 3.0 Cleanup MODULARIZED: Check the code base for remants of modularized #ifdef's in the code and configuration system. -- Key: TS-71 URL: https://issues.apache.org/jira/browse/TS-71 Project: Traffic Server Issue Type: Improvement Components: Cleanup Affects Versions: 2.0.0a Environment: All Reporter: George Paul Assignee: George Paul Priority: Minor Fix For: 3.0 The code base has #ifdef's related to modularization of Traffic Server. The affected code needs to be reviewed and either incorporated (i.e. made the default) or removed from the base system. -George -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
