[jira] [Assigned] (TS-1205) Crash report: double free when RecDataSet in cluster mode
[
https://issues.apache.org/jira/browse/TS-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1205:
-
Assignee: kuotai
may or may not be the problem of clustering, need more investing into the
RecCore & cluster mode config syncing
> Crash report: double free when RecDataSet in cluster mode
> -
>
> Key: TS-1205
> URL: https://issues.apache.org/jira/browse/TS-1205
> Project: Traffic Server
> Issue Type: Bug
> Components: Clustering, Configuration
>Affects Versions: 3.1.3
> Environment: v3.0.x, with cluster mode 2
>Reporter: Zhao Yongming
>Assignee: kuotai
> Fix For: 3.3.0
>
>
> we have seen some config system syncing config files in cluster mode.
> {code}
> *** glibc detected *** /usr/bin/traffic_server: double free or corruption
> (fasttop): 0x2b639c0009a0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3f8f0750c6]
> /usr/bin/traffic_server(RecDataSet(RecDataT, RecData*,
> RecData*)+0xb8)[0x65dd58]
> /usr/bin/traffic_server(RecForceInsert(RecRecord*)+0x74)[0x6584b4]
> /usr/bin/traffic_server[0x65cd62]
> /usr/bin/traffic_server(RecMessageRecvThis(void*, char*, int)+0x16)[0x65ed46]
> /usr/bin/traffic_server(BaseManager::executeMgmtCallback(int, char*,
> int)+0x3d)[0x5b562d]
> /usr/bin/traffic_server(ProcessManager::processEventQueue()+0x29)[0x5b5d49]
> /usr/bin/traffic_server(startProcessManager(void*)+0x8d)[0x5b633d]
> /lib64/libpthread.so.0[0x3f8f4077f1]
> /lib64/libc.so.6(clone+0x6d)[0x3f8f0e570d]
> === Memory map:
> {code}
--
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-1203) Crash report: HdrHeap::duplicate_str, in host_set
[
https://issues.apache.org/jira/browse/TS-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1203:
-
Assignee: weijin
this issue is new rising in our evn, after the patch for hdrheap protecting,
maybe a blocker for us.
> Crash report: HdrHeap::duplicate_str, in host_set
> -
>
> Key: TS-1203
> URL: https://issues.apache.org/jira/browse/TS-1203
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.1.3
> Environment: 3.0.x, new crashes
>Reporter: Zhao Yongming
>Assignee: weijin
>
> we get some new crashes in the production:
> {code}
> warning: no loadable sections found in added symbol-file system-supplied DSO
> at 0x727fd000
> Core was generated by `/usr/bin/traffic_server -M -A,12:X,13:X'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
> (gdb) bt
> #0 0x003e5b07c24e in memcpy () from /lib64/libc.so.6
> #1 0x005aab68 in HdrHeap::duplicate_str (this=,
> str=0x2aae474a6ec0 ,
> nbytes=21) at HdrHeap.cc:344
> #2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
> s_str=0x2aae474a6ec0 , s_len=21,
> d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
> MIME.cc:3034
> #3 0x005aef28 in host_set (this=0x2aae268f8c18, url= out>) at URL.h:541
> #4 HTTPHdr::set_url_target_from_host_field (this=0x2aae268f8c18, url= optimized out>) at HTTP.cc:1484
> #5 0x0055dc69 in RemapProcessor::setup_for_remap (this= optimized out>, s=0x2aae268f83c8) at RemapProcessor.cc:130
> #6 0x005165d9 in HttpSM::do_remap_request (this=0x2aae268f8360,
> run_inline=true) at HttpSM.cc:3666
> #7 0x00526cbb in HttpSM::set_next_state (this=0x2aaabd62be12) at
> HttpSM.cc:6392
> #8 0x005136f0 in HttpSM::call_transact_and_set_next_state
> (this=0x2aae268f8360, f=) at HttpSM.cc:6345
> #9 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
> HttpSM.cc:6553
> #10 0x005136f0 in HttpSM::call_transact_and_set_next_state
> (this=0x2aae268f8360, f=) at HttpSM.cc:6345
> #11 0x00526713 in HttpSM::set_next_state (this=0x2aae268f8360) at
> HttpSM.cc:6553
> #12 0x005136f0 in HttpSM::call_transact_and_set_next_state
> (this=0x2aae268f8360, f=) at HttpSM.cc:6345
> #13 0x00520f21 in HttpSM::state_read_client_request_header
> (this=0x2aae268f8360, event=100, data=)
> at HttpSM.cc:783
> #14 0x005259b9 in HttpSM::main_handler (this=0x2aae268f8360,
> event=100, data=0x2aae68aee6e0) at HttpSM.cc:2456
> #15 0x0066d1fb in handleEvent (nh=0x2b105668, vc=0x2aae68aee520,
> thread=0x2b104010)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #16 read_signal_and_update (nh=0x2b105668, vc=0x2aae68aee520,
> thread=0x2b104010) at UnixNetVConnection.cc:138
> #17 read_from_net (nh=0x2b105668, vc=0x2aae68aee520,
> thread=0x2b104010) at UnixNetVConnection.cc:320
> #18 0x00666579 in NetHandler::mainNetEvent (this=0x2b105668,
> event=, e=0x2b8ed028) at UnixNet.cc:389
> #19 0x00691c8f in EThread::process_event (this=0x2b104010,
> e=0x35681c0, calling_code=5) at I_Continuation.h:146
> #20 0x0069259c in EThread::execute (this=0x2b104010) at
> UnixEThread.cc:263
> #21 0x0069115e in spawn_thread_internal (a=0x35621b0) at Thread.cc:88
> #22 0x003e5b80673d in start_thread () from /lib64/libpthread.so.0
> #23 0x003e5b0d44bd in clone () from /lib64/libc.so.6
> (gdb) f 1
> #1 0x005aab68 in HdrHeap::duplicate_str (this=,
> str=0x2aae474a6ec0 ,
> nbytes=21) at HdrHeap.cc:344
> 344 memcpy(new_str, str, nbytes);
> (gdb) p str
> $1 = 0x2aae474a6ec0
> (gdb) p nbytes
> $2 = 21
> (gdb) f 2
> #2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
> s_str=0x2aae474a6ec0 , s_len=21,
> d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
> MIME.cc:3034
> 3034 s_str = heap->duplicate_str(s_str, s_len);
> (gdb) p s_str
> $3 = 0x2aae474a6ec0
> (gdb) f 3
> #3 0x005aef28 in host_set (this=0x2aae268f8c18, url= out>) at URL.h:541
> 541 url_host_set(m_heap, m_url_impl, value, length, true);
> (gdb) p value
> $4 =
> (gdb) p length
> $5 =
> (gdb) f 2
> #2 0x005b3ac3 in mime_str_u16_set (heap=0x2aaabd62be12,
> s_str=0x2aae474a6ec0 , s_len=21,
> d_str=0x2aae3656f348, d_len=0x2aae3656f322, must_copy=true) at
> MIME.cc:3034
> 3034 s_str = heap->duplicate_str(s_str, s_len);
> (gdb) l
> 3029//either NULL or be valid ptr for a string already
> 3030//the string heaps
> 3031heap->free_string(*d_str, *d_len);
> 3032
> 3033if (must_copy && s_str) {
> 3034 s_str = heap->duplicate_str(s_str, s
[jira] [Assigned] (TS-1103) Traffic Server ESI plugin issues
[ https://issues.apache.org/jira/browse/TS-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-1103: - Assignee: Zhao Yongming > Traffic Server ESI plugin issues > > > Key: TS-1103 > URL: https://issues.apache.org/jira/browse/TS-1103 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: sometime > Environment: Newest trunk. >Reporter: Kevin Fox >Assignee: Zhao Yongming > Fix For: 3.1.4 > > Attachments: esi.patch, gzip.patch > > > Patch to fix: > * Makefile fix to add missing files. > * Change return code checking to match whats trunk trafficserver. > * Include missing header files. > * Fix c++ namespace issues. > * Work around strange name mangling/linking issue. > * Force the assumption that the cached data is RAW_ESI, not PACKED_ESI. > Things wouldn't work without it. > * Comment out a block of code that looked to be incorrectly handling > EOF. > After this, simply loading the plugin and setting response header X-ESI > in apache httpd seems to work. > A few further bugs I have bumped into that aren't addressed in this > patch: > * It doesn't seem to parse gzip like it looks like it should. To work > around, I had to disable it in apache httpd with "RewriteRule . - > [E=no-gzip:1]" > * If the client requests gzip, the ESI processor will gzip the result. > It works in firefox but is invalid in chrome. Pulling a dump with curl > and running it through gzip --list shows it has the correct uncompressed > size and compressed size. using zcat shows the correct data but has the > warning: "invalid compressed data--length error". As far as I read the > gzip spec though, the raw binary file looks valid to me. Not sure what > this is. This can probably be simply disabled for now though. > * esi:include is slightly broken. You get all the data back properly but > sometimes the headers are sent prematurely with a Content-Length of > 2**31-1. This causes clients to timeout and fail. I'm currently unsure > how to fix this. > I've tried a few of the more advanced esi features, including ensuring > cookies make it back to the origin server and things seem to work good. > So, once the above bugs are figured out (particularly the include one), > I think it will be in pretty good shape. -- 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-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1002:
-
Assignee: Zhao Yongming
> log unmapped HOST when pristine_host_hdr disabled
> -
>
> Key: TS-1002
> URL: https://issues.apache.org/jira/browse/TS-1002
> Project: Traffic Server
> Issue Type: Wish
> Components: Logging
>Reporter: Conan Wang
>Assignee: Zhao Yongming
>Priority: Minor
> Fix For: 3.1.5
>
>
> I want to log user request's "Host" in http header before remap. I write
> logs_xml.config, like: %<{Host}cqh>
> When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
> right "Host" which is not rewritten.
> When disable the config, I always get the rewritten/mapped "Host" which is
> not what I need.
> logs_xml reference:
> http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
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-1051) Updating logs_xml.config requires full restart
[
https://issues.apache.org/jira/browse/TS-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-1051:
-
Assignee: Zhao Yongming (was: Leif Hedstrom)
> Updating logs_xml.config requires full restart
> --
>
> Key: TS-1051
> URL: https://issues.apache.org/jira/browse/TS-1051
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.1.2
>Reporter: Billy Vierra
>Assignee: Zhao Yongming
> Fix For: 3.1.4
>
>
> Using SVN Rev: 1214051
> URL: http://svn.apache.org/repos/asf/trafficserver/traffic/trunk
> upon adding a new LogObject and doing traffic_line -x you get the following
> in traffic.out
> [Dec 14 12:31:48.533] Manager {0x7f2f2abef700} NOTE: User has changed config
> file logs_xml.config
> However it does not go into effect (new log is not created). Upon full
> restart: trafficserver stop, trafficserver start it will add the new log file
> as expected.
> Not sure if it is a bug with docs or in code.
--
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-968) During/after daily logfile roll, trafficserver seg faults (Sig 11)
[
https://issues.apache.org/jira/browse/TS-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming reassigned TS-968:
Assignee: Zhao Yongming
> During/after daily logfile roll, trafficserver seg faults (Sig 11)
> --
>
> Key: TS-968
> URL: https://issues.apache.org/jira/browse/TS-968
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.0.1
> Environment: Ubuntu 10.10, 2.6.35-24-virtual
>Reporter: Drew Rothstein
>Assignee: Zhao Yongming
> Fix For: 3.1.4
>
>
> Every day at 00:00:00 after/during the log file roll, I see a segfault. Here
> are the past couple days:
> [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
> /usr/local/var/log/trafficserver/error.log was rolled to
> /usr/local/var/log/trafficserver/error.log_trafficserver02.20110921.00h00m06s-20110922.00h00m00s.old.
> [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
> /usr/local/var/log/trafficserver/squid.log was rolled to
> /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
> [Sep 22 00:00:00.000] Server {47590596851456} STATUS: The logfile
> /usr/local/var/log/trafficserver/extended2.log was rolled to
> /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110921.00h00m01s-20110922.00h00m00s.old.
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> [Sep 22 00:00:17.729] Manager {140722071643936} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> [Sep 22 00:00:17.729] Manager {140722071643936} FATAL: (last system error
> 104: Connection reset by peer)
> [Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
> [LocalManager::mgmtShutdown] Executing shutdown request.
> [Sep 22 00:00:17.730] Manager {140722071643936} NOTE:
> [LocalManager::processShutdown] Executing process shutdown request.
> [Sep 22 00:00:17.730] Manager {140722071643936} ERROR:
> [LocalManager::sendMgmtMsgToProcesses] Error writing message
> [Sep 22 00:00:17.730] Manager {140722071643936} ERROR: (last system error
> 32: Broken pipe)
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
> [Sep 22 00:00:17.786] {140131209512736} STATUS: opened
> /usr/local/var/log/trafficserver/manager.log
> [Sep 22 00:00:17.786] {140131209512736} NOTE: updated diags config
> [Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
> [ClusterCom::ClusterCom] Node running on OS: 'Linux' Release:
> '2.6.35-24-virtual'
> [Sep 22 00:00:17.805] Manager {140131209512736} NOTE:
> [LocalManager::listenForProxy] Listening on port: 80
> [Sep 22 00:00:17.805] Manager {140131209512736} NOTE: [TrafficManager] Setup
> complete
> [Sep 22 00:00:18.827] Manager {140131209512736} NOTE:
> [LocalManager::startProxy] Launching ts process
> [TrafficServer] using root directory '/usr/local'
> [Sep 22 00:00:18.849] Manager {140131209512736} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '13'
> [Sep 22 00:00:18.849] Manager {140131209512736} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Sep 22 00:00:19.874] {47510015031936} STATUS: opened
> /usr/local/var/log/trafficserver/diags.log
> [Sep 22 00:00:19.874] {47510015031936} NOTE: updated diags config
> [Sep 22 00:00:19.879] Server {47510015031936} NOTE: cache clustering disabled
> [Sep 22 00:00:19.908] Server {47510015031936} NOTE: cache clustering disabled
> [Sep 22 00:00:20.019] Server {47510015031936} NOTE: logging initialized[7],
> logging_mode = 3
> [Sep 22 00:00:20.032] Server {47510015031936} NOTE: traffic server running
> [Sep 22 00:00:20.045] Server {47510028859136} NOTE: cache enabled
> [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
> /usr/local/var/log/trafficserver/error.log was rolled to
> /usr/local/var/log/trafficserver/error.log_trafficserver02.20110922.00h00m11s-20110923.00h00m00s.old.
> [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
> /usr/local/var/log/trafficserver/squid.log was rolled to
> /usr/local/var/log/trafficserver/squid.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
> [Sep 23 00:00:00.000] Server {47409990321920} STATUS: The logfile
> /usr/local/var/log/trafficserver/extended2.log was rolled to
> /usr/local/var/log/trafficserver/extended2.log_trafficserver02.20110922.00h00m06s-20110923.00h00m00s.old.
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> [Sep 23 00:00:14.668] Manager {140131209512736} FATAL:
> [LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
> [Sep 23 00:00:14.668] Manager {140131209512736} FATAL: (last system error
> 104: Connection reset by peer)
> [Sep 23 00:00:14.668] Ma
[jira] [Assigned] (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:all-tabpanel
]
Zhao Yongming reassigned TS-857:
Assignee: weijin
weijin is working on threading & net crashing issue. he have got some
directions for this issue.
> 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.2
>
>
> 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 ink_stack_trace_get(void**, int, int)
> (ink_stack_trace.cc:68); saved rip 0x2ba641dccef1
> called by frame at 0x40e2bbe0
> source language c++.
> Arglist at 0x40e2b770, args: stack=, len= optimized out>, signalhandler_frame=
> Locals at 0x40e2b770, Previous frame's sp is 0x40e2b790
> Saved registers:
> rbx at 0x40e2b778, rbp at 0x40e2b780, rip at 0x40e2b788
> (gdb)
> {code}
--
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-899) ts crash
[ https://issues.apache.org/jira/browse/TS-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-899: Assignee: weijin this is more http transform problem for plugins, than a prefetch only problem, assign to weijin as he is working on it, feel free to comment > ts crash > > > Key: TS-899 > URL: https://issues.apache.org/jira/browse/TS-899 > Project: Traffic Server > Issue Type: Sub-task > Components: HTTP, MIME >Affects Versions: 3.0.1 > Environment: readhat5.5, ts-3.0.1, X86-64 >Reporter: weijin >Assignee: weijin > Fix For: 3.1.1 > > > If a request url is forbidden then redirected to another url, TS crash. -- 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
