[jira] [Commented] (TS-924) Performance improvements with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098664#comment-13098664 ] weijin commented on TS-924: --- yes。 I even have a immature idea, we first acquire the session of the same thread, if not, we create new session or acquire from the global sessions, that depends on the CONFIG proxy.config.http.share_server_sessions. > Performance improvements with second request on same keep-alive connection > -- > > Key: TS-924 > URL: https://issues.apache.org/jira/browse/TS-924 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.1.1 > > Attachments: TS-924.diff > > > This is a continuation of TS-880, it has more details. The idea is that we > committed the safe, but less optimal fix already with TS-880. Ideally though, > we should do something like William's first approach, and migrate origin > VConns to the same EThread as the UA VConn. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-168) LogBuffer.h/LogObject.h overload operator new and do object initialization there using iObject which is evil
[ https://issues.apache.org/jira/browse/TS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-168: - Attachment: TS-168-2.patch this is a 85KB patch which will revert most of the changes in the last patch, that will include iObject etc, and mutex locking. things beyond revert include: 1, make LogObject compare really works, not we do not close and then reopen the connections(when do remote logging), the files(when do local file logging) 2, rework the size based rolling with a simple way. this is a huge patch, may need full review and testing. > LogBuffer.h/LogObject.h overload operator new and do object initialization > there using iObject which is evil > > > Key: TS-168 > URL: https://issues.apache.org/jira/browse/TS-168 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: John Plevyak >Assignee: Zhao Yongming >Priority: Critical > Fix For: 3.1.1 > > Attachments: LogBuff.diff, TS-168-2.patch > > > In header LogBuffer.h the classes iObject/iObjectActivator/iLogBufferData > need to be cleaned up. > This code is terribly designed. Nobody should ever do object initialization > in an overloaded new operator. This caused TS-159. > The logging code was designed to be completely lockless on the critical path > and not to do any malloc/new (which typically involve locks) and this code > breaks that design. > Basically, this should be rewritten, perhaps someone for Y! could attach > the patch which added this junk so it can be backed out and whatever > real functionality it added, added in a reasonable way. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-924) Performance improvements with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099060#comment-13099060 ] Leif Hedstrom commented on TS-924: -- Hmmm, sounds complicated :). Maybe we should just make this option non-reloadable? I mean, how often would you change this on a live system anyways? > Performance improvements with second request on same keep-alive connection > -- > > Key: TS-924 > URL: https://issues.apache.org/jira/browse/TS-924 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.1.1 > > Attachments: TS-924.diff > > > This is a continuation of TS-880, it has more details. The idea is that we > committed the safe, but less optimal fix already with TS-880. Ideally though, > we should do something like William's first approach, and migrate origin > VConns to the same EThread as the UA VConn. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-946) Scheduling a continuation on all threads of a specific type
Scheduling a continuation on all threads of a specific type --- Key: TS-946 URL: https://issues.apache.org/jira/browse/TS-946 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Leif Hedstrom Fix For: 3.1.2 It would be incredibly useful, both in the core and in plugin APIs, to be able to schedule a continuation to run on all threads of a specific type. E.g. in a plugin, something like TSAction TSContScheduleOnThreads(TSCont cont, TSThreadPool tp); This would be useful for e.g. setting up per-thread specifics from a plugin, but quite possibly also from the core. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-947) AIO Race condition on non NT systems
AIO Race condition on non NT systems
Key: TS-947
URL: https://issues.apache.org/jira/browse/TS-947
Project: Traffic Server
Issue Type: Bug
Components: Core
Environment: stock build with static libts, running on a 4 core server
Reporter: B Wyatt
Refer to code below. The timeslice starting when a consumer thread determines
that the temp_list is empty (A) and ending when it releases the aio_mutex(C) is
unsafe if the work queues are empty and it breaks loop execution at B. During
this timeslice (A-C) the consumer holds the aio_mutex and as a result request
producers enqueue items on the temporary atomic list (D). As a consumer in
this state will wait for a signal on aio_cond to proceed before processing the
temp_list again, any requests on the temp_list are effectively stalled until a
future request produces this signal or manually processes the temp_list.
In the case of cache volume initialization, there is no "future request" and
the initialization sequence soft locks.
{code:title=iocore/aio/AIO.cc(annotated)}
void *
aio_thread_main(void *arg)
{
...
ink_mutex_acquire(&my_aio_req->aio_mutex);
for (;;) {
do {
current_req = my_aio_req;
/* check if any pending requests on the atomic list */
A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
aio_move(my_aio_req);
if (!(op = my_aio_req->aio_todo.pop()) && !(op =
my_aio_req->http_aio_todo.pop()))
B>>>break;
...
<>
...
} while (1);
C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
}
...
}
static void
aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
{
...
if (!ink_mutex_try_acquire(&req->aio_mutex)) {
D>>>ink_atomiclist_push(&req->aio_temp_list, op);
} else {
/* check if any pending requests on the atomic list */
if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
aio_move(req);
/* now put the new request */
aio_insert(op, req);
ink_cond_signal(&req->aio_cond);
ink_mutex_release(&req->aio_mutex);
}
...
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099273#comment-13099273
]
B Wyatt commented on TS-947:
I am testing a patch that removes the use of the atomic temp_list entirely.
Instead it relies on acquiring the aio_mutex for every request enqueue. This
may be sub-optimal, but it is preferable to occasional soft-locking on
initialization or request delays.
I have attached the patch.
> AIO Race condition on non NT systems
>
>
> Key: TS-947
> URL: https://issues.apache.org/jira/browse/TS-947
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: stock build with static libts, running on a 4 core server
>Reporter: B Wyatt
>
> Refer to code below. The timeslice starting when a consumer thread
> determines that the temp_list is empty (A) and ending when it releases the
> aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
> execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
> and as a result request producers enqueue items on the temporary atomic list
> (D). As a consumer in this state will wait for a signal on aio_cond to
> proceed before processing the temp_list again, any requests on the temp_list
> are effectively stalled until a future request produces this signal or
> manually processes the temp_list.
> In the case of cache volume initialization, there is no "future request" and
> the initialization sequence soft locks.
> {code:title=iocore/aio/AIO.cc(annotated)}
> void *
> aio_thread_main(void *arg)
> {
> ...
> ink_mutex_acquire(&my_aio_req->aio_mutex);
> for (;;) {
> do {
> current_req = my_aio_req;
> /* check if any pending requests on the atomic list */
> A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
> aio_move(my_aio_req);
> if (!(op = my_aio_req->aio_todo.pop()) && !(op =
> my_aio_req->http_aio_todo.pop()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
> }
> ...
> }
> static void
> aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
> {
> ...
> if (!ink_mutex_try_acquire(&req->aio_mutex)) {
> D>>>ink_atomiclist_push(&req->aio_temp_list, op);
> } else {
> /* check if any pending requests on the atomic list */
> if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
> aio_move(req);
> /* now put the new request */
> aio_insert(op, req);
> ink_cond_signal(&req->aio_cond);
> ink_mutex_release(&req->aio_mutex);
> }
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
B Wyatt updated TS-947:
---
Attachment: lock-safe-AIO.patch
> AIO Race condition on non NT systems
>
>
> Key: TS-947
> URL: https://issues.apache.org/jira/browse/TS-947
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: stock build with static libts, running on a 4 core server
>Reporter: B Wyatt
> Attachments: lock-safe-AIO.patch
>
>
> Refer to code below. The timeslice starting when a consumer thread
> determines that the temp_list is empty (A) and ending when it releases the
> aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
> execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
> and as a result request producers enqueue items on the temporary atomic list
> (D). As a consumer in this state will wait for a signal on aio_cond to
> proceed before processing the temp_list again, any requests on the temp_list
> are effectively stalled until a future request produces this signal or
> manually processes the temp_list.
> In the case of cache volume initialization, there is no "future request" and
> the initialization sequence soft locks.
> {code:title=iocore/aio/AIO.cc(annotated)}
> void *
> aio_thread_main(void *arg)
> {
> ...
> ink_mutex_acquire(&my_aio_req->aio_mutex);
> for (;;) {
> do {
> current_req = my_aio_req;
> /* check if any pending requests on the atomic list */
> A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
> aio_move(my_aio_req);
> if (!(op = my_aio_req->aio_todo.pop()) && !(op =
> my_aio_req->http_aio_todo.pop()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
> }
> ...
> }
> static void
> aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
> {
> ...
> if (!ink_mutex_try_acquire(&req->aio_mutex)) {
> D>>>ink_atomiclist_push(&req->aio_temp_list, op);
> } else {
> /* check if any pending requests on the atomic list */
> if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
> aio_move(req);
> /* now put the new request */
> aio_insert(op, req);
> ink_cond_signal(&req->aio_cond);
> ink_mutex_release(&req->aio_mutex);
> }
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-945) Incomplete URL when a tproxy request is sent to a parent proxy
[ https://issues.apache.org/jira/browse/TS-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-945: - Fix Version/s: 3.1.1 > Incomplete URL when a tproxy request is sent to a parent proxy > -- > > Key: TS-945 > URL: https://issues.apache.org/jira/browse/TS-945 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.1.0 >Reporter: Yossi Gottlieb > Fix For: 3.1.1 > > Attachments: tproxy-parent-fix.diff > > > The tproxy-intercepted request is a server-style URL (no host/port), while > the parent proxy expects a standard HTTP forward proxy URL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-943) Support for HTTP accept filter
[ https://issues.apache.org/jira/browse/TS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-943: - Fix Version/s: 3.1.1 > Support for HTTP accept filter > -- > > Key: TS-943 > URL: https://issues.apache.org/jira/browse/TS-943 > Project: Traffic Server > Issue Type: New Feature > Components: Network >Affects Versions: 3.1.0 >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle >Priority: Minor > Fix For: 3.1.1 > > Attachments: accept_filter.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Add support for accept filters (Solaris and FreeBSD) triggered by > proxy.config.net.defer_accept -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-947) AIO Race condition on non NT systems
[
https://issues.apache.org/jira/browse/TS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-947:
-
Fix Version/s: 3.1.1
> AIO Race condition on non NT systems
>
>
> Key: TS-947
> URL: https://issues.apache.org/jira/browse/TS-947
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: stock build with static libts, running on a 4 core server
>Reporter: B Wyatt
> Fix For: 3.1.1
>
> Attachments: lock-safe-AIO.patch
>
>
> Refer to code below. The timeslice starting when a consumer thread
> determines that the temp_list is empty (A) and ending when it releases the
> aio_mutex(C) is unsafe if the work queues are empty and it breaks loop
> execution at B. During this timeslice (A-C) the consumer holds the aio_mutex
> and as a result request producers enqueue items on the temporary atomic list
> (D). As a consumer in this state will wait for a signal on aio_cond to
> proceed before processing the temp_list again, any requests on the temp_list
> are effectively stalled until a future request produces this signal or
> manually processes the temp_list.
> In the case of cache volume initialization, there is no "future request" and
> the initialization sequence soft locks.
> {code:title=iocore/aio/AIO.cc(annotated)}
> void *
> aio_thread_main(void *arg)
> {
> ...
> ink_mutex_acquire(&my_aio_req->aio_mutex);
> for (;;) {
> do {
> current_req = my_aio_req;
> /* check if any pending requests on the atomic list */
> A>>> if (!INK_ATOMICLIST_EMPTY(my_aio_req->aio_temp_list))
> aio_move(my_aio_req);
> if (!(op = my_aio_req->aio_todo.pop()) && !(op =
> my_aio_req->http_aio_todo.pop()))
> B>>>break;
> ...
> <>
> ...
> } while (1);
> C>>>ink_cond_wait(&my_aio_req->aio_cond, &my_aio_req->aio_mutex);
> }
> ...
> }
> static void
> aio_queue_req(AIOCallbackInternal *op, int fromAPI = 0)
> {
> ...
> if (!ink_mutex_try_acquire(&req->aio_mutex)) {
> D>>>ink_atomiclist_push(&req->aio_temp_list, op);
> } else {
> /* check if any pending requests on the atomic list */
> if (!INK_ATOMICLIST_EMPTY(req->aio_temp_list))
> aio_move(req);
> /* now put the new request */
> aio_insert(op, req);
> ink_cond_signal(&req->aio_cond);
> ink_mutex_release(&req->aio_mutex);
> }
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-944) ssl.server.cert.path & ssl.server.private_key.path do not work as expected
[
https://issues.apache.org/jira/browse/TS-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-944:
-
Fix Version/s: 3.1.1
> ssl.server.cert.path & ssl.server.private_key.path do not work as expected
> --
>
> Key: TS-944
> URL: https://issues.apache.org/jira/browse/TS-944
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
>Affects Versions: 3.0.1
> Environment: CentOS 5.6
> TrafficServer 3.0.1
>Reporter: Ethan Lai
> Fix For: 3.1.1
>
>
> Weird behavior of ssl.server.cert.path & ssl.server.private_key.path
> Test config1:
> records.config:
> > CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
> > CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert
> > CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
> > CONFIG proxy.config.ssl.server.private_key.path STRING
> > /usr/local/etc/ats-cert
> ssl_multicert.config:
> > dest_ip=172.16.192.168 ssl_cert_name=cert2.pem ssl_key_name=cert2.key
> traffic.out:
> > ERROR: SSL::0:error:02001002:system library:fopen:No such file or
> > directory:bss_file.c:352:fopen('/usr/local/etc/ats-certcert2.pem','r')
> My observation:
> > *Trailing slash of ssl.server.cert.path not automatic added?*
> Test config2:
> records.config:
> > CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
> > CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert/
> > CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
> > CONFIG proxy.config.ssl.server.private_key.path STRING
> > /usr/local/etc/ats-cert/
> ssl_multicert.config:
> > dest_ip=172.16.192.168 ssl_cert_name=cert2.pem ssl_key_name=cert2.key
> traffic.out:
> > ERROR: SSL::0:error:02001002:system library:fopen:No such file or
> > directory:bss_file.c:352:fopen('/usr/local/etc/ats-certcert2.pem','r')
> My observation:
> > *Trailing slash of ssl.server.cert.path trimmed.*
> Test config3:
> records.config:
> > CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
> > CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert
> > CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
> > CONFIG proxy.config.ssl.server.private_key.path STRING
> > /usr/local/etc/ats-cert
> ssl_multicert.config:
> > dest_ip=210.71.204.149 ssl_cert_name=/cert2.pem ssl_key_name=cert2.key
> traffic.out:
> > ERROR: SSL::0:error:02001002:system library:fopen:No such file or
> > directory:bss_file.c:352:fopen('cert2.key','r')
> My observation:
> > *ssl.server.private_key.path config value not effective?*
> Test config4:
> records.config:
> > CONFIG proxy.config.ssl.server.cert.filename STRING
> > /usr/local/etc/ats-cert/cert1.pem
> > CONFIG proxy.config.ssl.server.cert.path STRING NULL
> > CONFIG proxy.config.ssl.server.private_key.filename STRING
> > /usr/local/etc/ats-cert/cert1.key
> > CONFIG proxy.config.ssl.server.private_key.path STRING NULL
> ssl_multicert.config:
> > dest_ip=210.71.204.149 ssl_cert_name=/usr/local/etc/ats-cert/cert2.pem
> > ssl_key_name=/usr/local/etc/ats-cert/cert2.key
> traffic.out:
> > ERROR: SSL::0:error:02001002:system library:fopen:No such file or
> > directory:bss_file.c:352:fopen('/usr/local/usr/local/etc/ats-cert/cert2.pem','r')
> My observation:
> > *prefix added before ssl_cert_name while ssl.server.cert.path not set*
> Test config5:
> records.config:
> > CONFIG proxy.config.ssl.server.cert.filename STRING
> > /usr/local/etc/ats-cert/cert1.pem
> > CONFIG proxy.config.ssl.server.cert.path STRING NULL
> > CONFIG proxy.config.ssl.server.private_key.filename STRING
> > /usr/local/etc/ats-cert/cert1.key
> > CONFIG proxy.config.ssl.server.private_key.path STRING NULL
> ssl_multicert.config:
> > dest_ip=210.71.204.149 ssl_cert_name=/etc/ats-cert/cert2.pem
> > ssl_key_name=/etc/ats-cert/cert2.key
> traffic.out:
> > ERROR: SSL::0:error:02001002:system library:fopen:No such file or
> > directory:bss_file.c:352:fopen('/etc/ats-cert/cert2.key','r')
> My observation:
> > *prefix NOT added before ssl_key_name while ssl.server.private_key.path not
> > set*
> Worked config:
> records.config:
> > CONFIG proxy.config.ssl.server.cert.filename STRING cert1.pem
> > CONFIG proxy.config.ssl.server.cert.path STRING /usr/local/etc/ats-cert
> > CONFIG proxy.config.ssl.server.private_key.filename STRING cert1.key
> > CONFIG proxy.config.ssl.server.private_key.path STRING
> > /usr/local/etc/ats-cert
> ssl_multicert.config:
> > dest_ip=210.71.204.149 ssl_cert_name=/cert2.pem
> > ssl_key_name=/usr/local/etc/ats-cert
> It seems ssl.server.cert.path has different (and weird) behavior with
> ssl.server.private_key.path.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-924) Performance improvements with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-924: - Attachment: TS-924-v2.diff Slight changes, moving bucket initialization out to thread creation. > Performance improvements with second request on same keep-alive connection > -- > > Key: TS-924 > URL: https://issues.apache.org/jira/browse/TS-924 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.1.1 > > Attachments: TS-924-v2.diff, TS-924.diff > > > This is a continuation of TS-880, it has more details. The idea is that we > committed the safe, but less optimal fix already with TS-880. Ideally though, > we should do something like William's first approach, and migrate origin > VConns to the same EThread as the UA VConn. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-924) Performance improvements with second request on same keep-alive connection
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099733#comment-13099733 ] weijin commented on TS-924: --- I tend to think that making this option non-reloadable is better, or else, the incompleteness would drive me crazy. haha > Performance improvements with second request on same keep-alive connection > -- > > Key: TS-924 > URL: https://issues.apache.org/jira/browse/TS-924 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Leif Hedstrom > Fix For: 3.1.1 > > Attachments: TS-924-v2.diff, TS-924.diff > > > This is a continuation of TS-880, it has more details. The idea is that we > committed the safe, but less optimal fix already with TS-880. Ideally though, > we should do something like William's first approach, and migrate origin > VConns to the same EThread as the UA VConn. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
