[jira] [Commented] (CASSANDRA-10984) Cassandra should not depend on netty-all
[
https://issues.apache.org/jira/browse/CASSANDRA-10984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090787#comment-15090787
]
Oleksandr Petrov commented on CASSANDRA-10984:
--
>From what I can see right now, it's `netty-buffer`, `codec`, `common`,
>`handler`, `transport`, `transport-native-epoll`
`netty-all` itself includes quite a few other things (such as DNS, example and
so on). Do you think a patch for that would be useful?
> Cassandra should not depend on netty-all
>
>
> Key: CASSANDRA-10984
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10984
> Project: Cassandra
> Issue Type: Improvement
>Reporter: James Roper
>Priority: Minor
>
> netty-all is a jar that bundles all the individual netty dependencies for
> convenience together for people trying out netty to get started quickly.
> Serious projects like Cassandra should never ever ever use it, since it's a
> recipe for classpath disasters.
> To illustrate, I'm running Cassandra embedded in an app, and I get this error:
> {noformat}
> [JVM-1] java.lang.NoSuchMethodError:
> io.netty.util.internal.PlatformDependent.newLongCounter()Lio/netty/util/internal/LongCounter;
> [JVM-1] at io.netty.buffer.PoolArena.(PoolArena.java:64)
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1] at
> io.netty.buffer.PoolArena$HeapArena.(PoolArena.java:593)
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1] at
> io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:179)
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1] at
> io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:153)
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1] at
> io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:145)
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1] at
> io.netty.buffer.PooledByteBufAllocator.(PooledByteBufAllocator.java:128)
> ~[netty-buffer-4.0.33.Final.jar:4.0.33.Final]
> [JVM-1] at
> org.apache.cassandra.transport.CBUtil.(CBUtil.java:56)
> ~[cassandra-all-3.0.0.jar:3.0.0]
> [JVM-1] at org.apache.cassandra.transport.Server.start(Server.java:134)
> ~[cassandra-all-3.0.0.jar:3.0.0]
> {noformat}
> {{PlatformDependent}} comes from netty-common, of which version 4.0.33 is on
> the classpath, but it's also provided by netty-all, which has version 4.0.23
> brought in by cassandra. By a fluke of classpath ordering, the classloader
> has loaded the netty buffer classes from netty-buffer 4.0.33, but the
> PlatformDependent class from netty-all 4.0.23, and these two versions are not
> binary compatible, hence the linkage error.
> Essentially to avoid these problems in serious projects, anyone that ever
> brings in cassandra is going to have to exclude the netty dependency from it,
> which is error prone, and when you get it wrong, due to the nature of
> classpath ordering bugs, it might not be till you deploy to production that
> you actually find out there's a problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-9257) Schema Builder does not support multiple column add/drop/alter
Oleksandr Petrov created CASSANDRA-9257:
---
Summary: Schema Builder does not support multiple column
add/drop/alter
Key: CASSANDRA-9257
URL: https://issues.apache.org/jira/browse/CASSANDRA-9257
Project: Cassandra
Issue Type: Improvement
Components: Drivers (now out of tree)
Reporter: Oleksandr Petrov
Right now, SchemaBuilder allows adding, altering or dropping only one column,
for example:
```
SchemaBuilder.alterTable("ks", "DropColumn")
.addColumn("b")
.type(DataType.cint()
```
There's no way to say `addColumn` after that once again, so one has to create
another statement.
I'd be glad to help out / contribute that one, if everyone generally agrees
that this is a good addition to API.
This would be a great addition, and will help one of Clojure drivers to provide
a smoother API, too.
Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-5504) Eternal iteration when using older hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696196#comment-13696196 ] Oleksandr Petrov edited comment on CASSANDRA-5504 at 6/29/13 8:55 PM: -- Can anyone confirm if 1.2.4 contains the fix, too? It seems to work, it's just not clear wether fix made it there or it's just a coincidence... UPDATE: sorry, I've tested against 1.2.5, so nevermind :) was (Author: ifesdjeen): Can anyone confirm if 1.2.4 contains the fix, too? It seems to work, it's just not clear wether fix made it there or it's just a coincidence... > Eternal iteration when using older hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.0 >Reporter: Oleksandr Petrov >Assignee: Oleksandr Petrov >Priority: Minor > Fix For: 1.2.5 > > Attachments: 5504-v3.txt, patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using older hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696196#comment-13696196 ] Oleksandr Petrov commented on CASSANDRA-5504: - Can anyone confirm if 1.2.4 contains the fix, too? It seems to work, it's just not clear wether fix made it there or it's just a coincidence... > Eternal iteration when using older hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.0 >Reporter: Oleksandr Petrov >Assignee: Oleksandr Petrov >Priority: Minor > Fix For: 1.2.5 > > Attachments: 5504-v3.txt, patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638317#comment-13638317 ] Oleksandr Petrov commented on CASSANDRA-5504: - However, unfortunately, when using it with Cascading, I still get eternal iterations :/ so it'd still be good if someone could take a look at the patch :/ > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638312#comment-13638312 ] Oleksandr Petrov commented on CASSANDRA-5504: - You can configure it through the ConfigHelper.setThriftMaxMessageLength(), can you execute java code there? > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638312#comment-13638312 ] Oleksandr Petrov edited comment on CASSANDRA-5504 at 4/22/13 6:52 PM: -- You can configure it through the ConfigHelper.setThriftMaxMessageLength(), can you execute java code there? (e.q. not only pig queries) was (Author: ifesdjeen): You can configure it through the ConfigHelper.setThriftMaxMessageLength(), can you execute java code there? > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638254#comment-13638254 ] Oleksandr Petrov commented on CASSANDRA-5504: - Hm... That's quite weird. Maybe there's something different with Thrift. I've seen people having trouble because of the message size, too, though. There're two settings, one for framed and one non-framed thrift. > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638178#comment-13638178 ] Oleksandr Petrov commented on CASSANDRA-5504: - Ben, I've been putting lastRowKey in a wrong place, now it's after get_range_slices occuring, which should be correct. I've had same exact stack trace. Hope that solves issue for you. > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleksandr Petrov updated CASSANDRA-5504: Attachment: patch2.diff > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch2.diff, patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638167#comment-13638167 ] Oleksandr Petrov commented on CASSANDRA-5504: - Sorry, my bad, I have forgotten to sync changes for static rows, give me a sec. Faced that one, too. > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleksandr Petrov updated CASSANDRA-5504: Attachment: patch.diff > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 1.2.3 >Reporter: Oleksandr Petrov >Priority: Critical > Attachments: patch.diff > > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
[ https://issues.apache.org/jira/browse/CASSANDRA-5504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleksandr Petrov updated CASSANDRA-5504: Description: Currently, when using newer hadoop versions, due to the call to next(ByteBuffer key, SortedMap value) within ColumnFamilyRecordReader, because `key.clear();` is called, key is emptied. That causes the StaticRowIterator and WideRowIterator to glitch, namely, when Iterables.getLast(rows).key is called, key is already empty. This will cause Hadoop to request the same range again and again all the time. Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) and saves it for the next iteration along with all the rows, this allows query for the next range to be fully correct. This patch is branched from 1.2.3 version. Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 > Eternal iteration when using newer hadoop version due to next() call and > empty key value > > > Key: CASSANDRA-5504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Reporter: Oleksandr Petrov >Priority: Critical > > Currently, when using newer hadoop versions, due to the call to > next(ByteBuffer key, SortedMap value) > within ColumnFamilyRecordReader, because `key.clear();` is called, key is > emptied. That causes the StaticRowIterator and WideRowIterator to glitch, > namely, when Iterables.getLast(rows).key is called, key is already empty. > This will cause Hadoop to request the same range again and again all the time. > Please see the attached patch/diff, it simply adds lastRowKey (ByteBuffer) > and saves it for the next iteration along with all the rows, this allows > query for the next range to be fully correct. > This patch is branched from 1.2.3 version. > Tested against Cassandra 1.2.3, with Hadoop 1.0.3, 1.0.4 and 0.20.2 -- 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-5504) Eternal iteration when using newer hadoop version due to next() call and empty key value
Oleksandr Petrov created CASSANDRA-5504: --- Summary: Eternal iteration when using newer hadoop version due to next() call and empty key value Key: CASSANDRA-5504 URL: https://issues.apache.org/jira/browse/CASSANDRA-5504 Project: Cassandra Issue Type: Bug Components: Hadoop Reporter: Oleksandr Petrov Priority: Critical -- 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
