[jira] [Commented] (CASSANDRA-4757) Expose bulk loading progress/status over jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13754864#comment-13754864 ] Greg DeAngelis commented on CASSANDRA-4757: --- Sorry that was an oversight by me. I will fix that today. Expose bulk loading progress/status over jmx Key: CASSANDRA-4757 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Assignee: Greg DeAngelis Priority: Minor Labels: lhf Fix For: 2.0 Attachments: CASSANDRA-4757.txt, CASSANDRA-4757v2.txt The bulk loading interface should be exposing some progress or status information over jmx. This shouldn't be too difficult and should be exposed in a way that the information is available whether you are using the separate sstableloader utility or calling the bulkload jmx call. -- 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-4757) Expose bulk loading progress/status over jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13754864#comment-13754864 ] Greg DeAngelis edited comment on CASSANDRA-4757 at 8/30/13 4:30 PM: Sorry that was an oversight by me. I believe sstableloader uses an int so i'll follow that and will fix it later today. was (Author: gdeangel): Sorry that was an oversight by me. I will fix that today. Expose bulk loading progress/status over jmx Key: CASSANDRA-4757 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Assignee: Greg DeAngelis Priority: Minor Labels: lhf Fix For: 2.0 Attachments: CASSANDRA-4757.txt, CASSANDRA-4757v2.txt The bulk loading interface should be exposing some progress or status information over jmx. This shouldn't be too difficult and should be exposed in a way that the information is available whether you are using the separate sstableloader utility or calling the bulkload jmx call. -- 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-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
Greg DeAngelis created CASSANDRA-5964:
-
Summary: cqlsh raises a ValueError when connecting to Cassandra
running in Eclipse
Key: CASSANDRA-5964
URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
Project: Cassandra
Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor
The release_version is set to 'Unknown' in system.local so the version parsing
logic fails.
Traceback (most recent call last):
File ./cqlsh, line 2027, in module
main(*read_options(sys.argv[1:], os.environ))
File ./cqlsh, line 2013, in main
display_float_precision=options.float_precision)
File ./cqlsh, line 486, in __init__
self.get_connection_versions()
File ./cqlsh, line 580, in get_connection_versions
self.cass_ver_tuple = tuple(map(int, vers['build'].split('-',
1)[0].split('.')[:3]))
ValueError: invalid literal for int() with base 10: 'Unknown'
--
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-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
[
https://issues.apache.org/jira/browse/CASSANDRA-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg DeAngelis updated CASSANDRA-5964:
--
Attachment: CASSANDRA-5964.patch
The error raised by cqlsh is a bit friendlier and I added an option
--unknownversion to allow cqlsh to pass the connection version parsing if the
version is 'Unknown'.
cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
-
Key: CASSANDRA-5964
URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
Project: Cassandra
Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor
Attachments: CASSANDRA-5964.patch
The release_version is set to 'Unknown' in system.local so the version
parsing logic fails.
Traceback (most recent call last):
File ./cqlsh, line 2027, in module
main(*read_options(sys.argv[1:], os.environ))
File ./cqlsh, line 2013, in main
display_float_precision=options.float_precision)
File ./cqlsh, line 486, in __init__
self.get_connection_versions()
File ./cqlsh, line 580, in get_connection_versions
self.cass_ver_tuple = tuple(map(int, vers['build'].split('-',
1)[0].split('.')[:3]))
ValueError: invalid literal for int() with base 10: 'Unknown'
--
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-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
[
https://issues.apache.org/jira/browse/CASSANDRA-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg DeAngelis updated CASSANDRA-5964:
--
Attachment: (was: CASSANDRA-5964.patch)
cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
-
Key: CASSANDRA-5964
URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
Project: Cassandra
Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor
The release_version is set to 'Unknown' in system.local so the version
parsing logic fails.
Traceback (most recent call last):
File ./cqlsh, line 2027, in module
main(*read_options(sys.argv[1:], os.environ))
File ./cqlsh, line 2013, in main
display_float_precision=options.float_precision)
File ./cqlsh, line 486, in __init__
self.get_connection_versions()
File ./cqlsh, line 580, in get_connection_versions
self.cass_ver_tuple = tuple(map(int, vers['build'].split('-',
1)[0].split('.')[:3]))
ValueError: invalid literal for int() with base 10: 'Unknown'
--
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] [Issue Comment Deleted] (CASSANDRA-5964) cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
[
https://issues.apache.org/jira/browse/CASSANDRA-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg DeAngelis updated CASSANDRA-5964:
--
Comment: was deleted
(was: The error raised by cqlsh is a bit friendlier and I added an option
--unknownversion to allow cqlsh to pass the connection version parsing if the
version is 'Unknown'.)
cqlsh raises a ValueError when connecting to Cassandra running in Eclipse
-
Key: CASSANDRA-5964
URL: https://issues.apache.org/jira/browse/CASSANDRA-5964
Project: Cassandra
Issue Type: Bug
Reporter: Greg DeAngelis
Priority: Minor
The release_version is set to 'Unknown' in system.local so the version
parsing logic fails.
Traceback (most recent call last):
File ./cqlsh, line 2027, in module
main(*read_options(sys.argv[1:], os.environ))
File ./cqlsh, line 2013, in main
display_float_precision=options.float_precision)
File ./cqlsh, line 486, in __init__
self.get_connection_versions()
File ./cqlsh, line 580, in get_connection_versions
self.cass_ver_tuple = tuple(map(int, vers['build'].split('-',
1)[0].split('.')[:3]))
ValueError: invalid literal for int() with base 10: 'Unknown'
--
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-5433) Nodetool - Human Readable
[ https://issues.apache.org/jira/browse/CASSANDRA-5433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg DeAngelis updated CASSANDRA-5433: -- Assignee: Greg DeAngelis Nodetool - Human Readable - Key: CASSANDRA-5433 URL: https://issues.apache.org/jira/browse/CASSANDRA-5433 Project: Cassandra Issue Type: Improvement Reporter: Brooke Bryan Assignee: Greg DeAngelis Priority: Trivial Attachments: humanreadablecompactionstats.patch Would be great to have a human readable option in nodetool to easily look stats without having to convert bytes to MB/GB etc in your head :) We have several internal scripts we use to parse the output to a more readable output, and would be useful for it to be part of nodetool itself. -- 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-4809) Allow restoring specific column families from archived commitlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751695#comment-13751695 ] Greg DeAngelis commented on CASSANDRA-4809: --- Are there any special considerations for system tables? Should they always be replayed regardless of what the user specifies to replay? Should this should be available as a property in commitlog_archiving.properties and the restore jmx call? Allow restoring specific column families from archived commitlog Key: CASSANDRA-4809 URL: https://issues.apache.org/jira/browse/CASSANDRA-4809 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 Reporter: Nick Bailey Labels: lhf Fix For: 2.0.1 Currently you can only restore the entire contents of a commit log archive. It would be useful to specify the keyspaces/column families you want to restore from an archived commitlog. -- 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-4809) Allow restoring specific column families from archived commitlog
[ https://issues.apache.org/jira/browse/CASSANDRA-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751743#comment-13751743 ] Greg DeAngelis commented on CASSANDRA-4809: --- Ok gotcha, I'll take the keyspaces and column families to replay as provided. Allow restoring specific column families from archived commitlog Key: CASSANDRA-4809 URL: https://issues.apache.org/jira/browse/CASSANDRA-4809 Project: Cassandra Issue Type: Improvement Affects Versions: 1.2.0 Reporter: Nick Bailey Labels: lhf Fix For: 2.0.1 Currently you can only restore the entire contents of a commit log archive. It would be useful to specify the keyspaces/column families you want to restore from an archived commitlog. -- 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-4757) Expose bulk loading progress/status over jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg DeAngelis updated CASSANDRA-4757: -- Attachment: CASSANDRA-4757v2.txt Expose bulk loading progress/status over jmx Key: CASSANDRA-4757 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Assignee: Greg DeAngelis Priority: Minor Labels: lhf Attachments: CASSANDRA-4757.txt, CASSANDRA-4757v2.txt The bulk loading interface should be exposing some progress or status information over jmx. This shouldn't be too difficult and should be exposed in a way that the information is available whether you are using the separate sstableloader utility or calling the bulkload jmx call. -- 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-4757) Expose bulk loading progress/status over jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13750261#comment-13750261 ] Greg DeAngelis commented on CASSANDRA-4757: --- Yuki, Thanks for the comments. The v2 patch should address your suggestions. Expose bulk loading progress/status over jmx Key: CASSANDRA-4757 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Assignee: Greg DeAngelis Priority: Minor Labels: lhf Attachments: CASSANDRA-4757.txt, CASSANDRA-4757v2.txt The bulk loading interface should be exposing some progress or status information over jmx. This shouldn't be too difficult and should be exposed in a way that the information is available whether you are using the separate sstableloader utility or calling the bulkload jmx call. -- 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-4757) Expose bulk loading progress/status over jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749702#comment-13749702 ] Greg DeAngelis commented on CASSANDRA-4757: --- It looks like each stream has a set of sessions that maintain the current state of all files being sent and received. Would it be sufficient to roll that session data up and expose it on the jmx interface for each stream? It would be pretty easy to expose the current and total rx and tx values as well as a percentage. Expose bulk loading progress/status over jmx Key: CASSANDRA-4757 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Priority: Minor Labels: lhf The bulk loading interface should be exposing some progress or status information over jmx. This shouldn't be too difficult and should be exposed in a way that the information is available whether you are using the separate sstableloader utility or calling the bulkload jmx call. -- 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-4757) Expose bulk loading progress/status over jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg DeAngelis updated CASSANDRA-4757: -- Attachment: CASSANDRA-4757.txt Expose bulk loading progress/status over jmx Key: CASSANDRA-4757 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Priority: Minor Labels: lhf Attachments: CASSANDRA-4757.txt The bulk loading interface should be exposing some progress or status information over jmx. This shouldn't be too difficult and should be exposed in a way that the information is available whether you are using the separate sstableloader utility or calling the bulkload jmx call. -- 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-4757) Expose bulk loading progress/status over jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13749748#comment-13749748 ] Greg DeAngelis commented on CASSANDRA-4757: --- Ok so given that, does the patch I just submitted bring anything to the table? Can the stream plan id be used as a correlation id? Expose bulk loading progress/status over jmx Key: CASSANDRA-4757 URL: https://issues.apache.org/jira/browse/CASSANDRA-4757 Project: Cassandra Issue Type: Improvement Reporter: Nick Bailey Priority: Minor Labels: lhf Attachments: CASSANDRA-4757.txt The bulk loading interface should be exposing some progress or status information over jmx. This shouldn't be too difficult and should be exposed in a way that the information is available whether you are using the separate sstableloader utility or calling the bulkload jmx call. -- 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-4551) Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter
[ https://issues.apache.org/jira/browse/CASSANDRA-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747718#comment-13747718 ] Greg DeAngelis commented on CASSANDRA-4551: --- I did not see the same issue with nodetool.bat. Seems to work fine. Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter --- Key: CASSANDRA-4551 URL: https://issues.apache.org/jira/browse/CASSANDRA-4551 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.9 Reporter: Mark Valdez Assignee: Greg DeAngelis Priority: Trivial Labels: datastax_qa, lhf Attachments: CASSANDRA-4551.txt Nodetool getendpoints keys do not work with embedded spaces, key_validation=ascii value of key = a test no delimiter tried to escape key = a test with double and single quotes. It doesn't work. It just reiterates the format of the tool's command: getendpoints requires ks, cf and key args -- 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-4551) Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter
[ https://issues.apache.org/jira/browse/CASSANDRA-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747247#comment-13747247 ] Greg DeAngelis commented on CASSANDRA-4551: --- I'm not sure about that but I can try to double check tomorrow if I can get access to a Windows machine. Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter --- Key: CASSANDRA-4551 URL: https://issues.apache.org/jira/browse/CASSANDRA-4551 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.9 Reporter: Mark Valdez Assignee: Greg DeAngelis Priority: Trivial Labels: datastax_qa, lhf Attachments: CASSANDRA-4551.txt Nodetool getendpoints keys do not work with embedded spaces, key_validation=ascii value of key = a test no delimiter tried to escape key = a test with double and single quotes. It doesn't work. It just reiterates the format of the tool's command: getendpoints requires ks, cf and key args -- 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-4952) Add blocking force compaction (and anything else) calls to NodeProbe
[ https://issues.apache.org/jira/browse/CASSANDRA-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745736#comment-13745736 ] Greg DeAngelis commented on CASSANDRA-4952: --- I think I misinterpreted what was being asked for. After digging further I realized that the compaction command exposed via nodetool already does a blocking compaction. Given that, is this ticket still valid? Add blocking force compaction (and anything else) calls to NodeProbe Key: CASSANDRA-4952 URL: https://issues.apache.org/jira/browse/CASSANDRA-4952 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.6 Reporter: Michael Harris Priority: Minor Labels: lhf There are times when I'd like to get feedback about when compactions complete. For example, if I'm deleting data from cassandra and want to know when it is 100% removed from cassandra (tombstones collected and all). This is completely trivial to implement based on the existing code (the method called by the non-blocking version returns a future, so you could just wait on that, potentially with a timeout). -- 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-4551) Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter
[ https://issues.apache.org/jira/browse/CASSANDRA-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745748#comment-13745748 ] Greg DeAngelis commented on CASSANDRA-4551: --- The documentation for nodetool getendpoints says that the key must be in hex format. Is the key being entered as the string a test or the hex representation? Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter --- Key: CASSANDRA-4551 URL: https://issues.apache.org/jira/browse/CASSANDRA-4551 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.9 Reporter: Mark Valdez Priority: Trivial Labels: datastax_qa, lhf Nodetool getendpoints keys do not work with embedded spaces, key_validation=ascii value of key = a test no delimiter tried to escape key = a test with double and single quotes. It doesn't work. It just reiterates the format of the tool's command: getendpoints requires ks, cf and key args -- 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-4551) Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter
[ https://issues.apache.org/jira/browse/CASSANDRA-4551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg DeAngelis updated CASSANDRA-4551: -- Attachment: CASSANDRA-4551.txt Nodetool getendpoints keys do not work with spaces, key_validation=ascii value of key = a test no delimiter --- Key: CASSANDRA-4551 URL: https://issues.apache.org/jira/browse/CASSANDRA-4551 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 1.0.9 Reporter: Mark Valdez Priority: Trivial Labels: datastax_qa, lhf Attachments: CASSANDRA-4551.txt Nodetool getendpoints keys do not work with embedded spaces, key_validation=ascii value of key = a test no delimiter tried to escape key = a test with double and single quotes. It doesn't work. It just reiterates the format of the tool's command: getendpoints requires ks, cf and key args -- 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-4952) Add blocking force compaction (and anything else) calls to NodeProbe
[ https://issues.apache.org/jira/browse/CASSANDRA-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13741820#comment-13741820 ] Greg DeAngelis commented on CASSANDRA-4952: --- Hi I'm new to the project and would like to start contributing. Before I try to work on this I just wanted to validate what I think needs to be done. As I understand it, what is being asked for is a blocking version of forceUserDefinedCompaction. This looks like it involves following what is done in forceUserDefinedCompaction for creating the list of keyspace/column family pairs, using the work done to construct the runnable in submitUserDefined (minus the executor.submit) to create a list of runnables then calling executor.invokeAll with some default timeout. Does this sound about right? Add blocking force compaction (and anything else) calls to NodeProbe Key: CASSANDRA-4952 URL: https://issues.apache.org/jira/browse/CASSANDRA-4952 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.1.6 Reporter: Michael Harris Priority: Minor Labels: lhf There are times when I'd like to get feedback about when compactions complete. For example, if I'm deleting data from cassandra and want to know when it is 100% removed from cassandra (tombstones collected and all). This is completely trivial to implement based on the existing code (the method called by the non-blocking version returns a future, so you could just wait on that, potentially with a timeout). -- 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
