[jira] [Created] (CASSANDRA-5520) Query tracing session info inconsistent with events info
Ilya Kirnos created CASSANDRA-5520: -- Summary: Query tracing session info inconsistent with events info Key: CASSANDRA-5520 URL: https://issues.apache.org/jira/browse/CASSANDRA-5520 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.4 Environment: Linux Reporter: Ilya Kirnos Session info for a trace is showing that a query took > 10 seconds (it timed out). cqlsh:system_traces> select session_id, duration, request from sessions where session_id = c7e36a30-af3a-11e2-9ec9-772ec39805fe; session_id | duration | request --+--+ c7e36a30-af3a-11e2-9ec9-772ec39805fe | 1230 | multiget_slice However, the event-level breakdown shows no such large duration: cqlsh:system_traces> select * from events where session_id = c7e36a30-af3a-11e2-9ec9-772ec39805fe; session_id | event_id | activity | source | source_elapsed | thread --+--+--+++ c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a30-af3a-11e2-9480-e9d811e0fc18 | Message received from /50.112.90.147 |50.112.4.16 | 19 | Thread-57 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e36a31-af3a-11e2-9ec9-772ec39805fe | Sending message to /10.252.153.16 | 50.112.90.147 |246 | WRITE-/50.112.4.16 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9480-e9d811e0fc18 | Message received from /50.112.90.147 |50.112.4.16 |259 | Thread-57 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-9ec9-772ec39805fe | Sending message to /10.248.106.37 | 50.112.90.147 |253 | WRITE-/50.112.79.52 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39140-af3a-11e2-b8dc-a7032a583115 | Message received from /50.112.90.147 | 50.112.213.136 | 25 | Thread-94 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9480-e9d811e0fc18 | Executing single-partition query on CardHash |50.112.4.16 |421 | ReadStage:5329 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-9ec9-772ec39805fe | Sending message to /10.252.151.214 | 50.112.90.147 |310 | WRITE-/50.112.213.136 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39141-af3a-11e2-b8dc-a7032a583115 | Message received from /50.112.90.147 | 50.112.213.136 |106 | Thread-94 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9480-e9d811e0fc18 | Acquiring sstable references |50.112.4.16 |444 | ReadStage:5329 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-9ec9-772ec39805fe | Sending message to /10.248.106.37 | 50.112.90.147 |352 | WRITE-/50.112.79.52 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39142-af3a-11e2-b8dc-a7032a583115 | Executing single-partition query on CardHash | 50.112.213.136 |144 | ReadStage:11 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9480-e9d811e0fc18 | Merging memtable contents |50.112.4.16 |472 | ReadStage:5329 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-9ec9-772ec39805fe | Sending message to /10.248.95.237 | 50.112.90.147 |362 | WRITE-/50.112.201.218 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39143-af3a-11e2-b8dc-a7032a583115 | Acquiring sstable references | 50.112.213.136 |164 | ReadStage:11 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9480-e9d811e0fc18 | Merging data from memtables and 0 sstables |50.112.4.16 |510 | ReadStage:5329 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-9ec9-772ec39805fe | Sending message to /10.252.151.214 | 50.112.90.147 |376 | WRITE-/50.112.213.136 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39144-af3a-11e2-b8dc-a7032a583115 | Merging memtable contents | 50.112.213.136 |195 | ReadStage:11 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9480-e9d811e0fc18 | Read 0 live cells and 0 tombstoned |50.112.4.16 |530 | ReadStage:5329 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-9ec9-772ec39805fe | Sending message to /10.248.95.237 | 50.112.90.147 |401 | WRITE-/50.112.201.218 c7e36a30-af3a-11e2-9ec9-772ec39805fe | c7e39145-af3a-11e2-b8dc-a7032a583115 | Executing single-partition query on CardHash | 50.112.213
[jira] [Commented] (CASSANDRA-5506) Reduce memory consumption of IndexSummary
[ https://issues.apache.org/jira/browse/CASSANDRA-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643920#comment-13643920 ] Vijay commented on CASSANDRA-5506: -- +1 for the patch and +1 for a separate ticket. > Reduce memory consumption of IndexSummary > - > > Key: CASSANDRA-5506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5506 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nick Puz >Assignee: Jonathan Ellis > Fix For: 1.2.5 > > > I am evaluating cassandra for a use case with many tiny rows which would > result in a node with 1-3TB of storage having billions of rows. Before > loading that much data I am hitting GC issues and when looking at the heap > dump I noticed that 70+% of the memory was used by IndexSummaries. > The two major issues seem to be: > 1) that the positions are stored as an ArrayList which results in each > position taking 24 bytes (class + flags + 8 byte long). This might make sense > when the file is initially written but once it has been serialized it would > be a lot more memory efficient to just have an long[] (really a int[] would > be fine unless 2GB sstables are allowed). > 2) The DecoratedKey for a byte[16] key takes 195 bytes -- this is for the > overhead of the ByteBuffer in the key and overhead in the token. > To somewhat "work around" the problem I have increased index_sample but will > this many rows that didn't really help starts to have diminishing returns. > NOTE: This heap dump was from linux with a 64bit oracle vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5506) Reduce memory consumption of IndexSummary
[ https://issues.apache.org/jira/browse/CASSANDRA-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5506: -- Reviewer: vijay2...@yahoo.com (was: yukim) > Reduce memory consumption of IndexSummary > - > > Key: CASSANDRA-5506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5506 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nick Puz >Assignee: Jonathan Ellis > Fix For: 1.2.5 > > > I am evaluating cassandra for a use case with many tiny rows which would > result in a node with 1-3TB of storage having billions of rows. Before > loading that much data I am hitting GC issues and when looking at the heap > dump I noticed that 70+% of the memory was used by IndexSummaries. > The two major issues seem to be: > 1) that the positions are stored as an ArrayList which results in each > position taking 24 bytes (class + flags + 8 byte long). This might make sense > when the file is initially written but once it has been serialized it would > be a lot more memory efficient to just have an long[] (really a int[] would > be fine unless 2GB sstables are allowed). > 2) The DecoratedKey for a byte[16] key takes 195 bytes -- this is for the > overhead of the ByteBuffer in the key and overhead in the token. > To somewhat "work around" the problem I have increased index_sample but will > this many rows that didn't really help starts to have diminishing returns. > NOTE: This heap dump was from linux with a 64bit oracle vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5506) Reduce memory consumption of IndexSummary
[ https://issues.apache.org/jira/browse/CASSANDRA-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643917#comment-13643917 ] Jonathan Ellis commented on CASSANDRA-5506: --- I'm pretty comfortable switching the representation for 1.2.5; let's make a separate ticket to move off heap for 2.0. > Reduce memory consumption of IndexSummary > - > > Key: CASSANDRA-5506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5506 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nick Puz >Assignee: Jonathan Ellis > Fix For: 1.2.5 > > > I am evaluating cassandra for a use case with many tiny rows which would > result in a node with 1-3TB of storage having billions of rows. Before > loading that much data I am hitting GC issues and when looking at the heap > dump I noticed that 70+% of the memory was used by IndexSummaries. > The two major issues seem to be: > 1) that the positions are stored as an ArrayList which results in each > position taking 24 bytes (class + flags + 8 byte long). This might make sense > when the file is initially written but once it has been serialized it would > be a lot more memory efficient to just have an long[] (really a int[] would > be fine unless 2GB sstables are allowed). > 2) The DecoratedKey for a byte[16] key takes 195 bytes -- this is for the > overhead of the ByteBuffer in the key and overhead in the token. > To somewhat "work around" the problem I have increased index_sample but will > this many rows that didn't really help starts to have diminishing returns. > NOTE: This heap dump was from linux with a 64bit oracle vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5506) Reduce memory consumption of IndexSummary
[ https://issues.apache.org/jira/browse/CASSANDRA-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643906#comment-13643906 ] Vijay edited comment on CASSANDRA-5506 at 4/28/13 5:10 AM: --- I have been thinking about moving IS off-heap for a while, I am really happy to see this ticket... Just wanted to try and add value :) Instead of storing the long[] and byte[][] in memory, can we store the indexes/pointers of the decorated key in memory... which will be helpful to address the off-heap decorated key's and offset? For example: During the binary search, we can use offheap indexes.length to find the midpoint in memory then reference it back to offheap BB which will be deserialized as needed (Summary effectively becomes a contiguous off-heap location)? was (Author: vijay2...@yahoo.com): I have been thinking about moving IS off-heap for a while, I am really happy to see this ticket... Just wanted to try to add value :) Instead of storing the long[] and byte[][] in memory, can we store the indexes/pointers of the decorated key in memory... which will be helpful to address the off-heap decorated key's and offset? For example: During the binary search, we can use offheap indexes.length to find the midpoint in memory then reference it back to offheap BB which will be deserialized as needed (Summary effectively becomes a contiguous off-heap location)? > Reduce memory consumption of IndexSummary > - > > Key: CASSANDRA-5506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5506 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nick Puz >Assignee: Jonathan Ellis > Fix For: 1.2.5 > > > I am evaluating cassandra for a use case with many tiny rows which would > result in a node with 1-3TB of storage having billions of rows. Before > loading that much data I am hitting GC issues and when looking at the heap > dump I noticed that 70+% of the memory was used by IndexSummaries. > The two major issues seem to be: > 1) that the positions are stored as an ArrayList which results in each > position taking 24 bytes (class + flags + 8 byte long). This might make sense > when the file is initially written but once it has been serialized it would > be a lot more memory efficient to just have an long[] (really a int[] would > be fine unless 2GB sstables are allowed). > 2) The DecoratedKey for a byte[16] key takes 195 bytes -- this is for the > overhead of the ByteBuffer in the key and overhead in the token. > To somewhat "work around" the problem I have increased index_sample but will > this many rows that didn't really help starts to have diminishing returns. > NOTE: This heap dump was from linux with a 64bit oracle vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5506) Reduce memory consumption of IndexSummary
[ https://issues.apache.org/jira/browse/CASSANDRA-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643906#comment-13643906 ] Vijay edited comment on CASSANDRA-5506 at 4/28/13 5:10 AM: --- I have been thinking about moving IS off-heap for a while, I am really happy to see this ticket... Just wanted to try to add value :) Instead of storing the long[] and byte[][] in memory, can we store the indexes/pointers of the decorated key in memory... which will be helpful to address the off-heap decorated key's and offset? For example: During the binary search, we can use offheap indexes.length to find the midpoint in memory then reference it back to offheap BB which will be deserialized as needed (Summary effectively becomes a contiguous off-heap location)? was (Author: vijay2...@yahoo.com): Instead of storing the long[] and byte[][] in memory, can we store the indexes/pointers of the decorated key in memory... which will be helpful to address the off-heap decorated key's and offset? For example: During the binary search, we can use offheap indexes.length to find the midpoint in memory then reference it back to offheap BB which will be deserialized as needed (Summary effectively becomes a contiguous off-heap location)? > Reduce memory consumption of IndexSummary > - > > Key: CASSANDRA-5506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5506 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nick Puz >Assignee: Jonathan Ellis > Fix For: 1.2.5 > > > I am evaluating cassandra for a use case with many tiny rows which would > result in a node with 1-3TB of storage having billions of rows. Before > loading that much data I am hitting GC issues and when looking at the heap > dump I noticed that 70+% of the memory was used by IndexSummaries. > The two major issues seem to be: > 1) that the positions are stored as an ArrayList which results in each > position taking 24 bytes (class + flags + 8 byte long). This might make sense > when the file is initially written but once it has been serialized it would > be a lot more memory efficient to just have an long[] (really a int[] would > be fine unless 2GB sstables are allowed). > 2) The DecoratedKey for a byte[16] key takes 195 bytes -- this is for the > overhead of the ByteBuffer in the key and overhead in the token. > To somewhat "work around" the problem I have increased index_sample but will > this many rows that didn't really help starts to have diminishing returns. > NOTE: This heap dump was from linux with a 64bit oracle vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5506) Reduce memory consumption of IndexSummary
[ https://issues.apache.org/jira/browse/CASSANDRA-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643906#comment-13643906 ] Vijay commented on CASSANDRA-5506: -- Instead of storing the long[] and byte[][] in memory, can we store the indexes/pointers of the decorated key in memory... which will be helpful to address the off-heap decorated key's and offset? For example: During the binary search, we can use offheap indexes.length to find the midpoint in memory then reference it back to offheap BB which will be deserialized as needed (Summary effectively becomes a contiguous off-heap location)? > Reduce memory consumption of IndexSummary > - > > Key: CASSANDRA-5506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5506 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nick Puz >Assignee: Jonathan Ellis > Fix For: 1.2.5 > > > I am evaluating cassandra for a use case with many tiny rows which would > result in a node with 1-3TB of storage having billions of rows. Before > loading that much data I am hitting GC issues and when looking at the heap > dump I noticed that 70+% of the memory was used by IndexSummaries. > The two major issues seem to be: > 1) that the positions are stored as an ArrayList which results in each > position taking 24 bytes (class + flags + 8 byte long). This might make sense > when the file is initially written but once it has been serialized it would > be a lot more memory efficient to just have an long[] (really a int[] would > be fine unless 2GB sstables are allowed). > 2) The DecoratedKey for a byte[16] key takes 195 bytes -- this is for the > overhead of the ByteBuffer in the key and overhead in the token. > To somewhat "work around" the problem I have increased index_sample but will > this many rows that didn't really help starts to have diminishing returns. > NOTE: This heap dump was from linux with a 64bit oracle vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4324) Implement Lucene FST in for key index
[ https://issues.apache.org/jira/browse/CASSANDRA-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-4324: -- Reviewer: (was: yukim) Does CASSANDRA-5506 make this obsolete? ISTM that the savings here can only come from the Token, since the keys themselves will not be ordered appropriately. (That is: CASSANDRA-5506 orders the keys by token, but only stores the underlying key byte[], and regenerates the token when necessary.) > Implement Lucene FST in for key index > - > > Key: CASSANDRA-4324 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4324 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Rutherglen >Assignee: Jason Rutherglen >Priority: Minor > Attachments: CASSANDRA-4324.patch, CASSANDRA-4324.patch, > CASSANDRA-4324.patch, lucene-core-4.0-SNAPSHOT.jar > > > The Lucene FST data structure offers a compact and fast system for indexing > Cassandra keys. More keys may be loaded which in turn should seeks faster. > * Update the IndexSummary class to make use of the Lucene FST, overriding the > serialization mechanism. > * Alter SSTableReader to make use of the FST seek mechanism -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5506) Reduce memory consumption of IndexSummary
[ https://issues.apache.org/jira/browse/CASSANDRA-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5506: -- Reviewer: yukim Priority: Major (was: Minor) Fix Version/s: 1.2.5 Assignee: Jonathan Ellis https://github.com/jbellis/cassandra/commits/5506 makes IndexSummary use a long[] and byte[][] to save memory. (I'm fairly confident the performance hit for re-decorating during index lookups will be negligible, since we only have to do the lookup on cache miss.) > Reduce memory consumption of IndexSummary > - > > Key: CASSANDRA-5506 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5506 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Nick Puz >Assignee: Jonathan Ellis > Fix For: 1.2.5 > > > I am evaluating cassandra for a use case with many tiny rows which would > result in a node with 1-3TB of storage having billions of rows. Before > loading that much data I am hitting GC issues and when looking at the heap > dump I noticed that 70+% of the memory was used by IndexSummaries. > The two major issues seem to be: > 1) that the positions are stored as an ArrayList which results in each > position taking 24 bytes (class + flags + 8 byte long). This might make sense > when the file is initially written but once it has been serialized it would > be a lot more memory efficient to just have an long[] (really a int[] would > be fine unless 2GB sstables are allowed). > 2) The DecoratedKey for a byte[16] key takes 195 bytes -- this is for the > overhead of the ByteBuffer in the key and overhead in the token. > To somewhat "work around" the problem I have increased index_sample but will > this many rows that didn't really help starts to have diminishing returns. > NOTE: This heap dump was from linux with a 64bit oracle vm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-5519) Reduce index summary memory use for cold sstables
Jonathan Ellis created CASSANDRA-5519: - Summary: Reduce index summary memory use for cold sstables Key: CASSANDRA-5519 URL: https://issues.apache.org/jira/browse/CASSANDRA-5519 Project: Cassandra Issue Type: Bug Components: Core Reporter: Jonathan Ellis Priority: Minor Fix For: 2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-5150) sstable2json doesn't check SIGPIPE
[ https://issues.apache.org/jira/browse/CASSANDRA-5150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643664#comment-13643664 ] Pawel Mirski commented on CASSANDRA-5150: - In patch there is checkError every entry write, which causes flush. Maybe better idea is to call checkError once per few entries to improve performance? > sstable2json doesn't check SIGPIPE > -- > > Key: CASSANDRA-5150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5150 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 2.0 >Reporter: Will Oberman >Priority: Minor > Labels: lhf > Attachments: trunk-5150.txt > > > I believe this explains the issue better than I can: > http://stackoverflow.com/questions/11695500/how-do-i-get-java-to-exit-when-piped-to-head. > Basically, I expected that if I did: "sstable2json SSTABLE | other-process", > and other-process had issues and/or died then the sstable2json process would > die. It doesn't. > My workaround is using mkfifo FILE, and having sstable2json write to FILE, > other-process read from FILE, and a 3rd overall process make sure the other > two processes are working. But, it would be _much_ simplier if sstable2json > failed on SIGPIPE. > I looks like the fix is to periodically check System.out.checkError() in the > Java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5150) sstable2json doesn't check SIGPIPE
[ https://issues.apache.org/jira/browse/CASSANDRA-5150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pawel Mirski updated CASSANDRA-5150: Attachment: trunk-5150.txt Patch in attachment. > sstable2json doesn't check SIGPIPE > -- > > Key: CASSANDRA-5150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5150 > Project: Cassandra > Issue Type: Bug > Components: Tools >Affects Versions: 2.0 >Reporter: Will Oberman >Priority: Minor > Labels: lhf > Attachments: trunk-5150.txt > > > I believe this explains the issue better than I can: > http://stackoverflow.com/questions/11695500/how-do-i-get-java-to-exit-when-piped-to-head. > Basically, I expected that if I did: "sstable2json SSTABLE | other-process", > and other-process had issues and/or died then the sstable2json process would > die. It doesn't. > My workaround is using mkfifo FILE, and having sstable2json write to FILE, > other-process read from FILE, and a 3rd overall process make sure the other > two processes are working. But, it would be _much_ simplier if sstable2json > failed on SIGPIPE. > I looks like the fix is to periodically check System.out.checkError() in the > Java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
