[jira] [Created] (TS-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux
Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux -- Key: TS-1163 URL: https://issues.apache.org/jira/browse/TS-1163 Project: Traffic Server Issue Type: Bug Components: Cache Reporter: B Wyatt Assignee: B Wyatt Due to 32bit integers in both the trafficersever code and the ioctl used to determine raw disk size, the number of sectors reported to the cache storage system is bound to 0-0x. If a disk has 512 byte sectors and is larger than 2TB it will report (num_sectors % 0x) * 512 bytes avaliable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux
[ https://issues.apache.org/jira/browse/TS-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt updated TS-1163: Attachment: blkgetsize64.bwyatt.patch It will still be a little bit while I dig myself out of my hole and begin directly committing fixes to the repo. Until then, I've attached a patch here that should work on codebases as old as June 2011 that provides support for larger disks via the BLKGETSIZE64 ioctl on linux. > Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on > linux > -- > > Key: TS-1163 > URL: https://issues.apache.org/jira/browse/TS-1163 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: B Wyatt >Assignee: B Wyatt > Attachments: blkgetsize64.bwyatt.patch > > > Due to 32bit integers in both the trafficersever code and the ioctl used to > determine raw disk size, the number of sectors reported to the cache storage > system is bound to 0-0x. If a disk has 512 byte sectors and is > larger than 2TB it will report (num_sectors % 0x) * 512 bytes > avaliable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-857) Crash Report: HttpTunnel::chain_abort_all -> HttpServerSession::do_io_close -> UnixNetVConnection::do_io_close
[
https://issues.apache.org/jira/browse/TS-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236722#comment-13236722
]
Otto van der Schaaf commented on TS-857:
another trace, put here as per amc's request:
Program received signal SIGSEGV, Segmentation fault.
ink_atomiclist_push (l=0x100bb0, item=0x11a4f00) at ink_queue.cc:457
457 volatile_void_p *adr_of_next = (volatile_void_p *)
ADDRESS_OF_NEXT(item, l->offset);
(gdb) bt
#0 ink_atomiclist_push (l=0x100bb0, item=0x11a4f00) at ink_queue.cc:457
#1 0x006aab3b in ProtectedQueue::enqueue (this=0x100bb0, e=, fast_signal=false) at ProtectedQueue.cc:53
#2 0x00511ff6 in HttpClientSession::do_io_close (this=0x11b89b0,
alerrno=-1) at HttpClientSession.cc:331
#3 0x00522fba in HttpSM::tunnel_handler_ua (this=0x7fffeb726650,
event=103, c=0x7fffeb728270) at HttpSM.cc:3029
#4 0x00566006 in HttpTunnel::consumer_handler (this=0x7fffeb7281c8,
event=103, c=0x7fffeb728270) at HttpTunnel.cc:1232
#5 0x00566800 in HttpTunnel::finish_all_internal (this=0x7fffeb7281c8,
p=0x7fffeb7284b0, chain=false) at HttpTunnel.cc:1359
#6 0x00520680 in local_finish_all (p=0x7fffeb7284b0, this=) at HttpTunnel.h:311
#7 HttpSM::tunnel_handler_transform_read (this=0x7fffeb726650, event=104,
p=0x7fffeb7284b0) at HttpSM.cc:3572
#8 0x00565a6c in HttpTunnel::producer_handler (this=0x7fffeb7281c8,
event=104, p=0x7fffeb7284b0) at HttpTunnel.cc:1136
#9 0x00565eb0 in HttpTunnel::main_handler (this=0x7fffeb7281c8,
event=, data=) at HttpTunnel.cc:1452
#10 0x004e78c5 in TransformTerminus::handle_event (this=0x7fffe4036998,
event=, edata=) at Transform.cc:241
#11 0x006ac450 in handleEvent (data=0x11a4fc0, event=1, this=) at I_Continuation.h:146
#12 EThread::process_event (this=0x7474f010, e=0x11a4fc0, calling_code=1)
at UnixEThread.cc:142
#13 0x006ad01e in EThread::execute (this=0x7474f010) at
UnixEThread.cc:234
#14 0x0047d5f2 in main (argc=, argv=) at
Main.cc:1939
> Crash Report: HttpTunnel::chain_abort_all -> HttpServerSession::do_io_close
> -> UnixNetVConnection::do_io_close
> --
>
> Key: TS-857
> URL: https://issues.apache.org/jira/browse/TS-857
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Affects Versions: 3.1.0
> Environment: in my branch that is something same as 3.0.x
>Reporter: Zhao Yongming
>Assignee: weijin
> Fix For: 3.1.5
>
> Attachments: locking-jp1.patch, ts-857.diff, ts-857.diff, ts-857.diff
>
>
> here is the bt from the crash, some of the information is missing due to we
> have not enable the --enable-debug configure options.
> {code}
> [New process 7532]
> #0 ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> 68fp = (void **) (*fp);
> (gdb) bt
> #0 ink_stack_trace_get (stack=, len= out>, signalhandler_frame=)
> at ink_stack_trace.cc:68
> #1 0x2ba641dccef1 in ink_stack_trace_dump (sighandler_frame= optimized out>) at ink_stack_trace.cc:114
> #2 0x004df020 in signal_handler (sig=) at
> signals.cc:225
> #3
> #4 0x006a1ea9 in UnixNetVConnection::do_io_close (this=0x1cc9bd20,
> alerrno=)
> at ../../iocore/eventsystem/I_Lock.h:297
> #5 0x0051f1d0 in HttpServerSession::do_io_close
> (this=0x2aaab0042c80, alerrno=20600) at HttpServerSession.cc:127
> #6 0x0056d1e9 in HttpTunnel::chain_abort_all (this=0x2aabeeffdd70,
> p=0x2aabeeffdf68) at HttpTunnel.cc:1300
> #7 0x005269ca in HttpSM::tunnel_handler_ua (this=0x2aabeeffc070,
> event=104, c=0x2aabeeffdda8) at HttpSM.cc:2987
> #8 0x00571dfc in HttpTunnel::consumer_handler (this=0x2aabeeffdd70,
> event=104, c=0x2aabeeffdda8) at HttpTunnel.cc:1232
> #9 0x00572032 in HttpTunnel::main_handler (this=0x2aabeeffdd70,
> event=1088608784, data=)
> at HttpTunnel.cc:1456
> #10 0x006a6307 in write_to_net_io (nh=0x2b12d688, vc=0x1cc876e0,
> thread=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #11 0x0069ce97 in NetHandler::mainNetEvent (this=0x2b12d688,
> event=, e=0x171c1ed0) at UnixNet.cc:405
> #12 0x006cddaf in EThread::process_event (this=0x2b12c010,
> e=0x171c1ed0, calling_code=5) at I_Continuation.h:146
> #13 0x006ce6bc in EThread::execute (this=0x2b12c010) at
> UnixEThread.cc:262
> #14 0x006cd0ee in spawn_thread_internal (a=0x171b58f0) at Thread.cc:88
> #15 0x003c33c064a7 in start_thread () from /lib64/libpthread.so.0
> #16 0x003c330d3c2d in clone () from /lib64/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0x40e2b790:
> rip = 0x2ba641dccdf3 in in
[jira] [Created] (TS-1164) a race condition in cache init
a race condition in cache init --- Key: TS-1164 URL: https://issues.apache.org/jira/browse/TS-1164 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.0.0, 3.1.1 Environment: all Reporter: weijin Assignee: weijin Fix For: 3.1.6 there is a race condition in CacheProcessor::diskInitialized, which may lead to cache can not be enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1164) a race condition in cache init
[ https://issues.apache.org/jira/browse/TS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] weijin updated TS-1164: --- Attachment: taorui-cache.diff > a race condition in cache init > --- > > Key: TS-1164 > URL: https://issues.apache.org/jira/browse/TS-1164 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 3.1.1, 3.0.0 > Environment: all >Reporter: weijin >Assignee: weijin > Fix For: 3.1.6 > > Attachments: taorui-cache.diff > > > there is a race condition in CacheProcessor::diskInitialized, which may lead > to cache can not be enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1165) Health checks not working
Health checks not working - Key: TS-1165 URL: https://issues.apache.org/jira/browse/TS-1165 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.1.3 Reporter: Igor Brezac Fix For: 3.1.4 Health checks not working -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1165) Health checks not working
[ https://issues.apache.org/jira/browse/TS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-1165: --- Assignee: Alan M. Carroll > Health checks not working > - > > Key: TS-1165 > URL: https://issues.apache.org/jira/browse/TS-1165 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.3 >Reporter: Igor Brezac >Assignee: Alan M. Carroll > Fix For: 3.1.4 > > > Health checks not working -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1165) Health checks not working
[ https://issues.apache.org/jira/browse/TS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1165. - Resolution: Fixed Added method to get all HTTP method mask and used that for backdoor connections (which previously had a mask of 0). commit 225f26fa3d7cdcb54197245dd4728f7f0e75171d > Health checks not working > - > > Key: TS-1165 > URL: https://issues.apache.org/jira/browse/TS-1165 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.1.3 >Reporter: Igor Brezac >Assignee: Alan M. Carroll > Fix For: 3.1.4 > > > Health checks not working -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236961#comment-13236961 ] Leif Hedstrom commented on TS-1079: --- Uri, I get a few rejects on current trunk with the patch (not sure why, I didn't check). Any chance you can rebase with current trunk? > Add an API function to turn debugging on for specific transactions/sessions > --- > > Key: TS-1079 > URL: https://issues.apache.org/jira/browse/TS-1079 > Project: Traffic Server > Issue Type: Improvement > Components: Core, HTTP >Reporter: Uri Shachar >Priority: Minor > Fix For: 3.1.6 > > Attachments: debug_specific.patch, debug_specific_2.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > When attempting to troubleshoot issues on a production ATS system, it > is often impossible/difficult to turn on any of the 'high-volume' debug tags > like http due to the performance impact. > > This enhancement allows a plugin to set a debug flag for a specific txn/ssn, > and replaces some of the internal Debug calls with a new function that checks > if the flag is turned on, and outputs the debug line regardless of the tag if > it is (The diags enable/disable flag is still taken into account). > The API will also have TSDebugSpecific in order to allow plugins to use the > same functionality. > In addition, we might consider adding an internal config file (remap-like) to > allow turning this flag on without plugin intervention. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-827) TSMimeHdrFieldValueStringInsert() can use freed memory to edit headers
[ https://issues.apache.org/jira/browse/TS-827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-827. -- Resolution: Fixed I think 793f3cfc0ccd01a4dae551af3aa3aa1a5ea77856 is a better solution. > TSMimeHdrFieldValueStringInsert() can use freed memory to edit headers > -- > > Key: TS-827 > URL: https://issues.apache.org/jira/browse/TS-827 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 3.1.4, 3.0.0, 3.1.0 > > Attachments: headers-prealloc.diff > > > TSMimeHdrFieldValueStringInsert() and other TSMimeHdrFieldValue*() APIs can > use freed memory to edit headers > due to calling HdrHeap::coalesce_str_heaps() from HdrHeap::allocate_str() from > mime_field_value_insert_comma_val() and other mime_field_value_*comma_val() > functions while holding pointers > into the HdrHeap. > I have a hacky but functional patch for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-827) TSMimeHdrFieldValueStringInsert() can use freed memory to edit headers
[ https://issues.apache.org/jira/browse/TS-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237400#comment-13237400 ] William Bardwell commented on TS-827: - That new fix looks good. > TSMimeHdrFieldValueStringInsert() can use freed memory to edit headers > -- > > Key: TS-827 > URL: https://issues.apache.org/jira/browse/TS-827 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Affects Versions: 2.1.9, 2.1.8, 2.1.7, 2.1.6, 2.1.5, 2.1.4 >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 3.1.4, 3.1.0, 3.0.0 > > Attachments: headers-prealloc.diff > > > TSMimeHdrFieldValueStringInsert() and other TSMimeHdrFieldValue*() APIs can > use freed memory to edit headers > due to calling HdrHeap::coalesce_str_heaps() from HdrHeap::allocate_str() from > mime_field_value_insert_comma_val() and other mime_field_value_*comma_val() > functions while holding pointers > into the HdrHeap. > I have a hacky but functional patch for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1125: -- Fix Version/s: 3.1.4 > POST's with Expect: 100-continue are slowed by delayed 100 response. > > > Key: TS-1125 > URL: https://issues.apache.org/jira/browse/TS-1125 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 > Environment: TS 3.0.2 going to Apache 2.2 web server >Reporter: William Bardwell >Priority: Minor > Fix For: 3.1.4 > > > Sending a post like: > POST / HTTP/1.1 > Host: www.example.com > Content-Length: 10 > Expect: 100-continue > directly to the web server immediately sends back: > HTTP/1.1 100 Continue > And then when the post data is sent, a status 200 response comes back. > But when going through ATS the "HTTP/1.1 100 Continue" is not sent > immediately, and instead is sent after the POST data has been received. This > is legal, but it makes clients that are hoping for a 100 continue to wait a > little while hoping to get that, ATS should forward that response through > immediately. > Note: I see curl using "Expect: 100-continue" with > 1024 bytes of post data, > but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1161) insafe raw device in storage.config
[ https://issues.apache.org/jira/browse/TS-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1161: -- Fix Version/s: 3.1.4 > insafe raw device in storage.config > --- > > Key: TS-1161 > URL: https://issues.apache.org/jira/browse/TS-1161 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Zhao Yongming > Fix For: 3.1.4 > > > if you system is on /dev/sda and you put /dev/sda into storage.config, TS > will destroy the data on /dev/sda without any hesitate. > this is proved to be true, please do not try, trust me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1154) quick_filter on HEAD does not work
[ https://issues.apache.org/jira/browse/TS-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1154: -- Fix Version/s: 3.1.4 > quick_filter on HEAD does not work > -- > > Key: TS-1154 > URL: https://issues.apache.org/jira/browse/TS-1154 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Zhao Yongming >Assignee: weijin > Fix For: 3.1.4 > > Attachments: head_method.diff > > > we take quick filter as a good solution for some security concern, but when I > set it to 0x0733, it does not allow HEAD in, but setting as 0x0723 does that. > Weijin have the patch in our tree: > https://gitorious.org/trafficserver/taobao/commit/cb23b87d167da4074e047fabc94786003ee94e9a/diffs/db7d0e5be69988b531e8d1e4eea717e6d46df5cd > I will commit if no one complain in 2 days. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1119) fatal error when uploading gzip-transform plugin
[
https://issues.apache.org/jira/browse/TS-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1119:
--
Fix Version/s: 3.1.4
> fatal error when uploading gzip-transform plugin
>
>
> Key: TS-1119
> URL: https://issues.apache.org/jira/browse/TS-1119
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 3.0.2
>Reporter: angela asher
>Priority: Blocker
> Fix For: 3.1.4
>
> Attachments: gzip-transform.diff
>
>
> getting the following error on traffic.out when running the traffic server
> with gzip-transform plugin:
> [Feb 23 16:28:15.509] Server {47392853811680} DEBUG: (http) [13] calling
> plugin on hook TS_HTTP_READ_RESPONSE_HDR_HOOK at hook 0x35BBEE0
> FATAL: InkAPI.cc:3036: failed assert `sdk_sanity_check_null_ptr((void*)
> value_len_ptr) == TS_SUCCESS`
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/lib/libtsutil.so.3(ink_fatal_va+0x9d)[0x2b1a7ecca37d]
> /usr/local/lib/libtsutil.so.3(ink_fatal+0x88)[0x2b1a7ecca4d8]
> /usr/local/lib/libtsutil.so.3(_ink_assert+0x85)[0x2b1a7ecc8af5]
> /usr/local/bin/traffic_server(TSMimeHdrFieldValueStringGet+0x124)[0x4a9144]
> /usr/local/libexec/trafficserver/gzip-transform.so(+0x1bde)[0x2b1a8b3c7bde]
> /usr/local/libexec/trafficserver/gzip-transform.so(+0x27c4)[0x2b1a8b3c87c4]
> /usr/local/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x525)[0x52cfa5]
> /usr/local/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x420)[0x52f1c0]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x530568]
> /usr/local/bin/traffic_server[0x681dcb]
> /usr/local/bin/traffic_server[0x6848f1]
> /usr/local/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x2e2)[0x67d402]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6a9ce4]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x6aa673]
> /usr/local/bin/traffic_server(main+0x1128)[0x4c07e8]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x2b1a81092c5d]
> /usr/local/bin/traffic_server[0x47e0e9]
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Aborted
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
> No such file or directory)
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Feb 23 16:28:15.512] Manager {140400187066336} ERROR: (last system error 2:
> No such file or directory)
> [Feb 23 16:28:16.522] Manager {140400187066336} NOTE:
> [LocalManager::startProxy] Launching ts process
> [TrafficServer] using root directory '/usr/local'
> [Feb 23 16:28:16.527] Manager {140400187066336} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '11'
> [Feb 23 16:28:16.527] Manager {140400187066336} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Feb 23 16:28:17.539] {47668265021920} STATUS: opened
> /usr/local/var/log/trafficserver/diags.log
> [Feb 23 16:28:17.539] {47668265021920} NOTE: updated diags config
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Config:
> "/usr/local/etc/trafficserver/ae_ua.config"
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Opening config
> "/usr/local/etc/trafficserver/ae_ua.config"
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [HttpConfig::init_aeua_filter] - Added 0 REGEXP filters
> [Feb 23 16:28:17.541] Server {47668265021920} DEBUG: (http_aeua)
> [init_http_aeua_filter] - Total loaded 0 REGEXP for
> Accept-Enconding/User-Agent filtering
> [Feb 23 16:28:17.542] Server {47668265021920} NOTE: cache clustering disabled
> [Feb 23 16:28:17.543] Server {47668265021920} DEBUG: (dns) ink_dns_init:
> called with init_called = 0
> [Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns)
> localhost=isk-vsrv227
> [Feb 23 16:28:17.546] Server {47668265021920} DEBUG: (dns) Round-robin
> nameservers = 0
> [Feb 23 16:28:17.547] Server {47668265021920} NOTE: cache clustering disabled
> [Feb 23 16:28:17.568] Server {47668265021920} NOTE: logging initialized[7],
> logging_mode = 3
> [Feb 23 16:28:17.569] Server {47668265021920} NOTE: loading plugin
> '/usr/local/libexec/trafficserver/gzip-transform.so'
> [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
> proxy.config.http.redirection_enabled = 0
> [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
> proxy.config.http.number_of_redirections = 1
> [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_init)
> proxy.config.http.post_copy_size = 2048
> [Feb 23 16:28:17.570] Server {47668265021920} DEBUG: (http_tproxy) Primary
>
[jira] [Updated] (TS-1151) in some strange situation, cop will crash
[
https://issues.apache.org/jira/browse/TS-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1151:
--
Fix Version/s: 3.1.4
> in some strange situation, cop will crash
> -
>
> Key: TS-1151
> URL: https://issues.apache.org/jira/browse/TS-1151
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Zhao Yongming
>Assignee: Zhao Yongming
> Fix For: 3.1.4
>
>
> we get some strange crash, the manager & cop may die, we are not sure what
> that is, but I'd like to start one Issue here if we have other same issue.
> here is the log in /var/log/messages
> {code}
> Mar 19 10:08:24 cache172.cn77 kernel:: [1553138.961401] [ET_NET 2][17949]:
> segfault at 2aadf1387937 ip 003c5bc7bdbe sp 410f3188 error 4 in
> libc-2.5.so[3c5bc0+14d000]
> Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} FATAL:
> (last system error 104: Connection reset by peer)
> Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> Mar 19 10:08:27 cache172.cn77 traffic_manager[17935]: {0x7ff0c8d51720} ERROR:
> (last system error 32: Broken pipe)
> Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: cop received child status
> signal [17935 2816]
> Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: traffic_manager not
> running, making sure traffic_server is dead
> Mar 19 10:08:33 cache172.cn77 traffic_cop[17933]: spawning traffic_manager
> Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: --- Manager
> Starting ---
> Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: NOTE: Manager Version:
> Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
> at 09:55:44)
> Mar 19 10:08:40 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} STATUS:
> opened /var/log/trafficserver/manager.log
> Mar 19 10:08:46 cache172.cn77 traffic_cop[17933]: (cli test) unable to
> retrieve manager_binary
> Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: --- Server Starting
> ---
> Mar 19 10:08:54 cache172.cn77 traffic_server[2789]: NOTE: Server Version:
> Apache Traffic Server - traffic_server - 3.0.2 - (build # 299 on Mar 9 2012
> at 09:56:00)
> Mar 19 10:09:00 cache172.cn77 traffic_server[2789]: {0x2b5a8ef03970} STATUS:
> opened /var/log/trafficserver/diags.log
> Mar 19 10:14:02 cache172.cn77 kernel:: [1553476.364204] [ET_NET 0][2789]:
> segfault at 2aab1fa99ce3 ip 003c5bc7bdbe sp 7fff39743fa8 error 4 in
> libc-2.5.so[3c5bc0+14d000]
> Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} FATAL:
> (last system error 104: Connection reset by peer)
> Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> Mar 19 10:14:03 cache172.cn77 traffic_manager[2760]: {0x7fd03d265720} ERROR:
> (last system error 32: Broken pipe)
> {code}
> here is the message in traffic.out
> {code}
> Mar 19 10:11:06 cache162.cn77 kernel:: [2510081.212455] [ET_NET 3][319]:
> segfault at 2aaae6e986bc ip 003f7f27bdbe sp 40be2188 error 4 in
> libc-2.5.so[3f7f20+14d000]
> Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} FATAL:
> (last system error 104: Connection reset by peer)
> Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> Mar 19 10:11:09 cache162.cn77 traffic_manager[305]: {0x7fd3a665c720} ERROR:
> (last system error 32: Broken pipe)
> Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: cop received child status
> signal [305 2816]
> Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: traffic_manager not running,
> making sure traffic_server is dead
> Mar 19 10:11:09 cache162.cn77 traffic_cop[303]: spawning traffic_manager
> Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: --- Manager
> Starting ---
> Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: NOTE: Manager Version:
> Apache Traffic Server - traffic_manager - 3.0.2 - (build # 299 on Mar 9 2012
> at 09:55:44)
> Mar 19 10:11:16 cache162.cn77 traffic_manager[1227]: {0x7f8ae2f48720} STATUS:
> opened /var/log/trafficserver/manager.log
> Mar 19 10:11:23 cache162.cn77 traffic_cop[303]: (cli test) unable to retrieve
> manager_binary
> Mar 19 10:11:39 cache16
[jira] [Updated] (TS-1152) http_ui error,when i get http://localhost/cache/
[
https://issues.apache.org/jira/browse/TS-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1152:
--
Fix Version/s: 3.1.4
> http_ui error,when i get http://localhost/cache/
>
>
> Key: TS-1152
> URL: https://issues.apache.org/jira/browse/TS-1152
> Project: Traffic Server
> Issue Type: Bug
> Components: Web UI
>Affects Versions: 3.0.4
> Environment: centos 6 x86_64
>Reporter: bettydramit
> Fix For: 3.1.4
>
>
> When i enable http_ui ，I got follow error (get http://xxx.xxx.xxx.xxx/cache/)
> [Mar 19 16:46:17.778] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 16:46:17.778] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 16:46:19.089] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 16:46:19.090] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 16:46:20.763] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 16:46:20.763] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 16:58:21.906] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /robots.txt not valid autoconf file
> [Mar 19 16:58:21.906] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
> [Mar 19 17:01:43.703] Manager {13989191624} ERROR:
> [WebHttpHandleConnection] /favicon.ico not valid autoconf file
> [Mar 19 17:01:43.703] Manager {13989191624} ERROR: (last system error
> 11: Resource temporarily unavailable)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1147) deprecate records.config SSL configuration
[ https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1147: -- Fix Version/s: 3.1.4 > deprecate records.config SSL configuration > -- > > Key: TS-1147 > URL: https://issues.apache.org/jira/browse/TS-1147 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Priority: Minor > Fix For: 3.1.4 > > > Since ssl_multicert.config is a strict superset of the SSL certificate > configuration in records.config, we should deprecate configuring SSL > certificates in records.config and make ssl_multicert.config the One True Way. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1163) Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on linux
[ https://issues.apache.org/jira/browse/TS-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1163: -- Fix Version/s: 3.1.4 > Raw disks with more than (2^32)-1 sectors (usually 2TB) are not supported on > linux > -- > > Key: TS-1163 > URL: https://issues.apache.org/jira/browse/TS-1163 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Reporter: B Wyatt >Assignee: B Wyatt > Fix For: 3.1.4 > > Attachments: blkgetsize64.bwyatt.patch > > > Due to 32bit integers in both the trafficersever code and the ioctl used to > determine raw disk size, the number of sectors reported to the cache storage > system is bound to 0-0x. If a disk has 512 byte sectors and is > larger than 2TB it will report (num_sectors % 0x) * 512 bytes > avaliable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1162) UnixNetVConnection.cc assertion when accepting a TLS connection
[
https://issues.apache.org/jira/browse/TS-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1162:
--
Fix Version/s: 3.1.4
> UnixNetVConnection.cc assertion when accepting a TLS connection
> ---
>
> Key: TS-1162
> URL: https://issues.apache.org/jira/browse/TS-1162
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.4
>Reporter: James Peach
> Fix For: 3.1.4
>
>
> Trunk always crashes when accepting a TLS connection:
> FATAL: UnixNetVConnection.cc:801: failed assert `vio->mutex->thread_holding
> == this_ethread()`
> /opt/ats/bin/traffic_server - STACK TRACE:
> 0 libtsutil.3.dylib 0x00010c3e7ee7 ink_fatal + 359
> 1 libtsutil.3.dylib 0x00010c3e6e22 _ink_assert + 66
> 2 traffic_server 0x00010b9e6d9a
> _ZN18UnixNetVConnection11set_enabledEP3VIO + 90
> 3 traffic_server 0x00010b9e681d
> _ZN18UnixNetVConnection8reenableEP3VIO + 93
> 4 traffic_server 0x00010b7bfcd6 _ZN3VIO8reenableEv
> + 54
> 5 traffic_server 0x00010b9e5cd9
> _ZN18UnixNetVConnection10do_io_readEP12ContinuationxP9MIOBuffer + 297
> 6 traffic_server 0x00010b792611
> _ZN11VConnection5do_ioEiP12ContinuationxP9MIOBufferi + 129
> 7 traffic_server 0x00010b9d6da9
> _ZN21SSLNextProtocolAccept9mainEventEiPv + 329
> 8 traffic_server 0x00010b792229
> _ZN12Continuation11handleEventEiPv + 121
> 9 traffic_server 0x00010b9e89bd
> _ZN18UnixNetVConnection11acceptEventEiP5Event + 829
> 10 traffic_server 0x00010b792229
> _ZN12Continuation11handleEventEiPv + 121
> 11 traffic_server 0x00010ba0905d
> _ZN7EThread13process_eventEP5Eventi + 349
> 12 traffic_server 0x00010ba09367
> _ZN7EThread7executeEv + 215
> 13 traffic_server 0x00010ba080ed
> _ZL21spawn_thread_internalPv + 109
> 14 libsystem_c.dylib 0x7fff8fcb78bf _pthread_start +
> 335
> 15 libsystem_c.dylib 0x7fff8fcbab75 thread_start + 13
> [Mar 22 21:58:45.009] Manager {0x7fff79b01960} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort trap: 6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1132) Clean up usage of HDR_BUF_RONLY_HEAPS
[ https://issues.apache.org/jira/browse/TS-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1132: -- Fix Version/s: (was: 3.1.4) sometime This is partially fixed in TS-1150. Moving this out to "sometime" when we might need this feature. When we do, we should also make the header heap size configurable, and not static to 2kB > Clean up usage of HDR_BUF_RONLY_HEAPS > - > > Key: TS-1132 > URL: https://issues.apache.org/jira/browse/TS-1132 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: sometime > > > We should clean up the usage of HDR_BUF_RONLY_HEAPS, and not assume it's > always "3". In addition, we should consider making this configurable, via > either records.config, or at least configure.ac. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1162) UnixNetVConnection.cc assertion when accepting a TLS connection
[
https://issues.apache.org/jira/browse/TS-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237433#comment-13237433
]
James Peach commented on TS-1162:
-
Well I went back all the way to when NPN was first checked in and it still
crashes. I'm pretty confident that I checked in working code, so not really
sure what's up.
> UnixNetVConnection.cc assertion when accepting a TLS connection
> ---
>
> Key: TS-1162
> URL: https://issues.apache.org/jira/browse/TS-1162
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.4
>Reporter: James Peach
> Fix For: 3.1.4
>
>
> Trunk always crashes when accepting a TLS connection:
> FATAL: UnixNetVConnection.cc:801: failed assert `vio->mutex->thread_holding
> == this_ethread()`
> /opt/ats/bin/traffic_server - STACK TRACE:
> 0 libtsutil.3.dylib 0x00010c3e7ee7 ink_fatal + 359
> 1 libtsutil.3.dylib 0x00010c3e6e22 _ink_assert + 66
> 2 traffic_server 0x00010b9e6d9a
> _ZN18UnixNetVConnection11set_enabledEP3VIO + 90
> 3 traffic_server 0x00010b9e681d
> _ZN18UnixNetVConnection8reenableEP3VIO + 93
> 4 traffic_server 0x00010b7bfcd6 _ZN3VIO8reenableEv
> + 54
> 5 traffic_server 0x00010b9e5cd9
> _ZN18UnixNetVConnection10do_io_readEP12ContinuationxP9MIOBuffer + 297
> 6 traffic_server 0x00010b792611
> _ZN11VConnection5do_ioEiP12ContinuationxP9MIOBufferi + 129
> 7 traffic_server 0x00010b9d6da9
> _ZN21SSLNextProtocolAccept9mainEventEiPv + 329
> 8 traffic_server 0x00010b792229
> _ZN12Continuation11handleEventEiPv + 121
> 9 traffic_server 0x00010b9e89bd
> _ZN18UnixNetVConnection11acceptEventEiP5Event + 829
> 10 traffic_server 0x00010b792229
> _ZN12Continuation11handleEventEiPv + 121
> 11 traffic_server 0x00010ba0905d
> _ZN7EThread13process_eventEP5Eventi + 349
> 12 traffic_server 0x00010ba09367
> _ZN7EThread7executeEv + 215
> 13 traffic_server 0x00010ba080ed
> _ZL21spawn_thread_internalPv + 109
> 14 libsystem_c.dylib 0x7fff8fcb78bf _pthread_start +
> 335
> 15 libsystem_c.dylib 0x7fff8fcbab75 thread_start + 13
> [Mar 22 21:58:45.009] Manager {0x7fff79b01960} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort trap: 6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1162) UnixNetVConnection.cc assertion when accepting a TLS connection
[
https://issues.apache.org/jira/browse/TS-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237435#comment-13237435
]
James Peach commented on TS-1162:
-
But this doesn't make sense; reenable() handles the case where we are not
holding the log, but it calls set_enabled() which requires the calling thread
to be holding the lock
void
UnixNetVConnection::set_enabled(VIO *vio)
{
ink_debug_assert(vio->mutex->thread_holding == this_ethread());
...
}
void
UnixNetVConnection::reenable(VIO *vio)
{
if (STATE_FROM_VIO(vio)->enabled)
return;
set_enabled(vio);
if (!thread)
return;
EThread *t = vio->mutex->thread_holding;
ink_debug_assert(t == this_ethread());
ink_debug_assert(!closed);
if (nh->mutex->thread_holding == t) {
...
} else {
MUTEX_TRY_LOCK(lock, nh->mutex, t);
...
}
}
> UnixNetVConnection.cc assertion when accepting a TLS connection
> ---
>
> Key: TS-1162
> URL: https://issues.apache.org/jira/browse/TS-1162
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.4
>Reporter: James Peach
> Fix For: 3.1.4
>
>
> Trunk always crashes when accepting a TLS connection:
> FATAL: UnixNetVConnection.cc:801: failed assert `vio->mutex->thread_holding
> == this_ethread()`
> /opt/ats/bin/traffic_server - STACK TRACE:
> 0 libtsutil.3.dylib 0x00010c3e7ee7 ink_fatal + 359
> 1 libtsutil.3.dylib 0x00010c3e6e22 _ink_assert + 66
> 2 traffic_server 0x00010b9e6d9a
> _ZN18UnixNetVConnection11set_enabledEP3VIO + 90
> 3 traffic_server 0x00010b9e681d
> _ZN18UnixNetVConnection8reenableEP3VIO + 93
> 4 traffic_server 0x00010b7bfcd6 _ZN3VIO8reenableEv
> + 54
> 5 traffic_server 0x00010b9e5cd9
> _ZN18UnixNetVConnection10do_io_readEP12ContinuationxP9MIOBuffer + 297
> 6 traffic_server 0x00010b792611
> _ZN11VConnection5do_ioEiP12ContinuationxP9MIOBufferi + 129
> 7 traffic_server 0x00010b9d6da9
> _ZN21SSLNextProtocolAccept9mainEventEiPv + 329
> 8 traffic_server 0x00010b792229
> _ZN12Continuation11handleEventEiPv + 121
> 9 traffic_server 0x00010b9e89bd
> _ZN18UnixNetVConnection11acceptEventEiP5Event + 829
> 10 traffic_server 0x00010b792229
> _ZN12Continuation11handleEventEiPv + 121
> 11 traffic_server 0x00010ba0905d
> _ZN7EThread13process_eventEP5Eventi + 349
> 12 traffic_server 0x00010ba09367
> _ZN7EThread7executeEv + 215
> 13 traffic_server 0x00010ba080ed
> _ZL21spawn_thread_internalPv + 109
> 14 libsystem_c.dylib 0x7fff8fcb78bf _pthread_start +
> 335
> 15 libsystem_c.dylib 0x7fff8fcbab75 thread_start + 13
> [Mar 22 21:58:45.009] Manager {0x7fff79b01960} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort trap: 6
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
