[jira] [Commented] (CASSANDRA-5568) Invalid tracing info for execute_prepared_cql3_query
[
https://issues.apache.org/jira/browse/CASSANDRA-5568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13688922#comment-13688922
]
Pierre Chalamet commented on CASSANDRA-5568:
Oups. Didn't even think I could sink Cassandra with a simple insert and tracing
enabled. Thanks for the investigation.
Invalid tracing info for execute_prepared_cql3_query
Key: CASSANDRA-5568
URL: https://issues.apache.org/jira/browse/CASSANDRA-5568
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Windows 8 x64
Java HotSpot(TM) 64-Bit Server VM/1.7.0_11
Reporter: Pierre Chalamet
Assignee: Ryan McGuire
Priority: Minor
Attachments: 5568-logs.tar.gz, 5568_test.py
When using trace_next_query() then execute_prepared_cql3_query(), it looks
like tracing info are invalid (number of sessions/events and columns values
are wrong).
How to reproduce:
{code}
create keyspace Tests with replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
create table Tests.stresstest (strid varchar,intid int, primary key (strid))
{code}
and then executing the following prepared query 50,000 times:
{code}
insert into Tests.stresstest (intid, strid) values (?, ?)
{code}
produces the following results:
{code}
localhost select count(*) from Tests.stresstest
++
| count |
++
| 5 |
++
localhost select count(*) from system_traces.events
++
| count |
++
| 20832 |
++
localhost select count(*) from system_traces.sessions
++
| count |
++
| 26717 |
++
localhost select * from system_traces.sessions limit 10
+--+-+--++-+---+
| sessionid| coordinator | duration |
parameters | request | startedat |
+==+=+==++=+===+
| 9aefc263-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:55 PM |
+--+-+--++-+---+
| 9ce0bcf7-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:59 PM |
+--+-+--++-+---+
| 9dbe4ba4-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:17:00 PM |
+--+-+--++-+---+
| 9d4d3a54-bcdb-11e2-8c60-fb495ee6a12c | | 44 |
| | |
+--+-+--++-+---+
| 9a790bc1-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:55 PM |
+--+-+--++-+---+
| 9c992c98-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:58 PM |
+--+-+--++-+---+
| 9e27e2f6-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | 53 |
| execute_prepared_cql3_query | 5/14/2013 9:17:01 PM |
+--+-+--++-+---+
| 9b172074-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:56 PM |
[jira] [Created] (CASSANDRA-5568) Invalid tracing info for execute_prepared_cql3_query
Pierre Chalamet created CASSANDRA-5568:
--
Summary: Invalid tracing info for execute_prepared_cql3_query
Key: CASSANDRA-5568
URL: https://issues.apache.org/jira/browse/CASSANDRA-5568
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Environment: Windows 8 x64
Java HotSpot(TM) 64-Bit Server VM/1.7.0_11
Reporter: Pierre Chalamet
Priority: Minor
When using trace_next_query() then execute_prepared_cql3_query(), it looks like
tracing info are invalid (number of sessions/events and columns values are
wrong).
How to reproduce:
{code}
create keyspace Tests with replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
create table Tests.stresstest (strid varchar,intid int, primary key (strid))
{code}
and then executing the following prepared query 50,000 times:
{code}
insert into Tests.stresstest (intid, strid) values (?, ?)
{code}
produces the following results:
{code}
localhost select count(*) from Tests.stresstest
++
| count |
++
| 5 |
++
localhost select count(*) from system_traces.events
++
| count |
++
| 20832 |
++
localhost select count(*) from system_traces.sessions
++
| count |
++
| 26717 |
++
localhost select * from system_traces.sessions limit 10
+--+-+--++-+---+
| sessionid| coordinator | duration |
parameters | request | startedat |
+==+=+==++=+===+
| 9aefc263-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:55 PM |
+--+-+--++-+---+
| 9ce0bcf7-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:59 PM |
+--+-+--++-+---+
| 9dbe4ba4-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:17:00 PM |
+--+-+--++-+---+
| 9d4d3a54-bcdb-11e2-8c60-fb495ee6a12c | | 44 |
| | |
+--+-+--++-+---+
| 9a790bc1-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:55 PM |
+--+-+--++-+---+
| 9c992c98-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:58 PM |
+--+-+--++-+---+
| 9e27e2f6-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | 53 |
| execute_prepared_cql3_query | 5/14/2013 9:17:01 PM |
+--+-+--++-+---+
| 9b172074-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:56 PM |
+--+-+--++-+---+
| 9a7cdc53-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | 53 |
| execute_prepared_cql3_query | 5/14/2013 9:16:55 PM |
+--+-+--++-+---+
| 9b6eb654-bcdb-11e2-8c60-fb495ee6a12c | 127.0.0.1 | |
| execute_prepared_cql3_query | 5/14/2013 9:16:56 PM |
[jira] [Commented] (CASSANDRA-5474) failure when passing null parameter to prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632636#comment-13632636
]
Pierre Chalamet commented on CASSANDRA-5474:
Really not sure.
Here is the frame I'm sending, and this fails.
{code}
// header
1, 0, 125, 10
// len
0, 0, 0, 34
// body
// requestId
0, 16,
89, 179, 214, 186, 237, 103, 213, 192, 163, 206, 210, 158, 187, 66, 119, 197
// nb columns
0, 2,
// a = 1
0, 0, 0, 4
0, 0, 0, 1
// b = null
255, 255, 255, 255
// CL
0, 4
{code}
failure when passing null parameter to prepared statement
-
Key: CASSANDRA-5474
URL: https://issues.apache.org/jira/browse/CASSANDRA-5474
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Environment: windows 8 x64, 1.7.0_11-b21 x64
Reporter: Pierre Chalamet
I have a failure when passing a null parameter to the prepared statement
bellow when going through the cql 3 bin protocol:
{code}
Exec: CREATE KEYSPACE Tests WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
Exec: CREATE TABLE Tests.AllTypes (a int, b int, primary key (a))
Prepare: insert into Tests.AllTypes (a, b) values (?, ?)
{code}
Passing a=1 and b=null cause the following error:
{code}
DEBUG 23:07:23,315 Responding: RESULT PREPARED
59b3d6baed67d5c0a3ced29ebb4277c5 [a(tests, alltypes),
org.apache.cassandra.db.marshal.Int32Type][b(tests, alltypes),
org.apache.cassandra.db.marshal.Int32Type]
DEBUG 23:07:23,292 Compaction buckets are []
DEBUG 23:07:23,336 Received: EXECUTE 59b3d6baed67d5c0a3ced29ebb4277c5 with 2
values at consistency QUORUM
ERROR 23:07:23,338 Unexpected exception during request
java.lang.NullPointerException
at
org.apache.cassandra.db.marshal.Int32Type.validate(Int32Type.java:95)
at
org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:257)
at
org.apache.cassandra.cql3.Constants$Setter.execute(Constants.java:282)
at
org.apache.cassandra.cql3.statements.UpdateStatement.mutationForKey(UpdateStatement.java:250)
at
org.apache.cassandra.cql3.statements.UpdateStatement.getMutations(UpdateStatement.java:133)
at
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:92)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:132)
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:254)
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:122)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:45)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
DEBUG 23:07:23,337 No tasks available
DEBUG 23:07:23,341 request complete
DEBUG 23:07:23,343 Responding: ERROR SERVER_ERROR:
java.lang.NullPointerException
{code}
When serializing value for b, a bytes array of len -1 is transmitted
(accordingly to the spec):
{code}
[bytes] A [int] n, followed by n bytes if n = 0. If n 0,
no byte should follow and the value represented is `null`.
{code}
CASSANDRA-5081 added support for null params. Am I doing something wrong
there ? Thanks.
--
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-5474) failure when passing null parameter to prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633406#comment-13633406
]
Pierre Chalamet commented on CASSANDRA-5474:
You are totally right. Seems I did a huge mistake after applying patch
CASSANDRA-5468. Copied the wrong jar :(
Thanks for your patience!
failure when passing null parameter to prepared statement
-
Key: CASSANDRA-5474
URL: https://issues.apache.org/jira/browse/CASSANDRA-5474
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Environment: windows 8 x64, 1.7.0_11-b21 x64
Reporter: Pierre Chalamet
I have a failure when passing a null parameter to the prepared statement
bellow when going through the cql 3 bin protocol:
{code}
Exec: CREATE KEYSPACE Tests WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
Exec: CREATE TABLE Tests.AllTypes (a int, b int, primary key (a))
Prepare: insert into Tests.AllTypes (a, b) values (?, ?)
{code}
Passing a=1 and b=null cause the following error:
{code}
DEBUG 23:07:23,315 Responding: RESULT PREPARED
59b3d6baed67d5c0a3ced29ebb4277c5 [a(tests, alltypes),
org.apache.cassandra.db.marshal.Int32Type][b(tests, alltypes),
org.apache.cassandra.db.marshal.Int32Type]
DEBUG 23:07:23,292 Compaction buckets are []
DEBUG 23:07:23,336 Received: EXECUTE 59b3d6baed67d5c0a3ced29ebb4277c5 with 2
values at consistency QUORUM
ERROR 23:07:23,338 Unexpected exception during request
java.lang.NullPointerException
at
org.apache.cassandra.db.marshal.Int32Type.validate(Int32Type.java:95)
at
org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:257)
at
org.apache.cassandra.cql3.Constants$Setter.execute(Constants.java:282)
at
org.apache.cassandra.cql3.statements.UpdateStatement.mutationForKey(UpdateStatement.java:250)
at
org.apache.cassandra.cql3.statements.UpdateStatement.getMutations(UpdateStatement.java:133)
at
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:92)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:132)
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:254)
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:122)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:45)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
DEBUG 23:07:23,337 No tasks available
DEBUG 23:07:23,341 request complete
DEBUG 23:07:23,343 Responding: ERROR SERVER_ERROR:
java.lang.NullPointerException
{code}
When serializing value for b, a bytes array of len -1 is transmitted
(accordingly to the spec):
{code}
[bytes] A [int] n, followed by n bytes if n = 0. If n 0,
no byte should follow and the value represented is `null`.
{code}
CASSANDRA-5081 added support for null params. Am I doing something wrong
there ? Thanks.
--
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-4210) Support for variadic parameters list for in clause in prepared cql query
[
https://issues.apache.org/jira/browse/CASSANDRA-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13633424#comment-13633424
]
Pierre Chalamet commented on CASSANDRA-4210:
This is still a problem when trying to bind an IN parameter for prepared
statement even in 1.2.4. For what I've seen, the column spec returned after
preparing
{code}
select * from Town where key in (?)
{code}
just tells that the parameter is of type 'key', not a set of type 'key'.
This would be really nice for binary protocol driver to know they could bind a
set of value for such parameter (and I'm pretty sure this info is known when
the statement is prepared).
Support for variadic parameters list for in clause in prepared cql query
--
Key: CASSANDRA-4210
URL: https://issues.apache.org/jira/browse/CASSANDRA-4210
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Environment: prepared cql queries
Reporter: Pierre Chalamet
Priority: Minor
This query
{code}
select * from Town where key in (?)
{code}
only allows one parameter for '?'.
This means querying for 'Paris' and 'London' can't be executed in one step
with this prepared statement.
Current workarounds are:
* either execute the prepared query 2 times with 'Paris' then 'London'
* or prepare a new query {{select * from Town where key in (?, ?)}} and bind
the 2 parameters
Having a support for variadic parameters list with in clause could improve
performance:
* single hop to get the data
* // fetching server side
--
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-5468) Prepared statements from default keyspace are broken
[
https://issues.apache.org/jira/browse/CASSANDRA-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13632141#comment-13632141
]
Pierre Chalamet commented on CASSANDRA-5468:
works for me. Thanks.
Prepared statements from default keyspace are broken
Key: CASSANDRA-5468
URL: https://issues.apache.org/jira/browse/CASSANDRA-5468
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Environment: Windows 8 x64, java 1.7.0_11 x64
Reporter: Pierre Chalamet
Assignee: Aleksey Yeschenko
Fix For: 1.2.5
Attachments: 5468.txt
Tested under CQL 3 binary protocol.
Preparing a statement from the default keyspace of the connection (statement
scoped with keyspace) and then running it will always throw the error no
keyspace has been specified.
{code}
Exec: CREATE KEYSPACE Tests WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
Exec: CREATE TABLE Tests.AllTypes (a int, b int, primary key (a))
Prepare: insert into Tests.AllTypes (a, b) values (?, ?)
{code}
Exec prepared statement and exception no keyspace has been specified is
thrown.
Doing a use Tests before preparing the statement solves the issue.
This used to work in 1.2.3.
--
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-5474) failure when passing null parameter to prepared statement
Pierre Chalamet created CASSANDRA-5474:
--
Summary: failure when passing null parameter to prepared statement
Key: CASSANDRA-5474
URL: https://issues.apache.org/jira/browse/CASSANDRA-5474
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Environment: windows 8 x64, 1.7.0_11-b21 x64
Reporter: Pierre Chalamet
I have a failure when passing a null parameter to the prepared statement bellow
when going through the cql 3 bin protocol:
{code}
Exec: CREATE KEYSPACE Tests WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
Exec: CREATE TABLE Tests.AllTypes (a int, b int, primary key (a))
Prepare: insert into Tests.AllTypes (a, b) values (?, ?)
{code}
Passing a=1 and b=null cause the following error:
{code}
DEBUG 23:07:23,315 Responding: RESULT PREPARED 59b3d6baed67d5c0a3ced29ebb4277c5
[a(tests, alltypes), org.apache.cassandra.db.marshal.Int32Type][b(tests,
alltypes), org.apache.cassandra.db.marshal.Int32Type]
DEBUG 23:07:23,292 Compaction buckets are []
DEBUG 23:07:23,336 Received: EXECUTE 59b3d6baed67d5c0a3ced29ebb4277c5 with 2
values at consistency QUORUM
ERROR 23:07:23,338 Unexpected exception during request
java.lang.NullPointerException
at org.apache.cassandra.db.marshal.Int32Type.validate(Int32Type.java:95)
at
org.apache.cassandra.cql3.Constants$Marker.bindAndGet(Constants.java:257)
at
org.apache.cassandra.cql3.Constants$Setter.execute(Constants.java:282)
at
org.apache.cassandra.cql3.statements.UpdateStatement.mutationForKey(UpdateStatement.java:250)
at
org.apache.cassandra.cql3.statements.UpdateStatement.getMutations(UpdateStatement.java:133)
at
org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:92)
at
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:132)
at
org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:254)
at
org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:122)
at
org.apache.cassandra.transport.Message$Dispatcher.messageReceived(Message.java:287)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:75)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at
org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:45)
at
org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
DEBUG 23:07:23,337 No tasks available
DEBUG 23:07:23,341 request complete
DEBUG 23:07:23,343 Responding: ERROR SERVER_ERROR:
java.lang.NullPointerException
{code}
When serializing value for b, a bytes array of len -1 is transmitted
(accordingly to the spec):
{code}
[bytes] A [int] n, followed by n bytes if n = 0. If n 0,
no byte should follow and the value represented is `null`.
{code}
CASSANDRA-5081 added support for null params. Am I doing something wrong there
? Thanks.
--
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-5468) Prepared statement from default keyspace are broken
Pierre Chalamet created CASSANDRA-5468:
--
Summary: Prepared statement from default keyspace are broken
Key: CASSANDRA-5468
URL: https://issues.apache.org/jira/browse/CASSANDRA-5468
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Environment: Windows 8 x64, java 1.7.0_11 x64
Reporter: Pierre Chalamet
Tested under CQL 3 binary protocol.
Preparing a statement from the default keyspace of the connection (statement
scoped with keyspace) and then running it will always throw the error no
keyspace has been specified.
{code}
Exec: CREATE KEYSPACE Tests WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
Exec: CREATE TABLE Tests.AllTypes (a int, b int, primary key (a))
Prepare: insert into Tests.AllTypes (a, b) values (?, ?)
{code}
Exec prepared statement and exception no keyspace has been specified is
thrown.
Doing a use Tests before preparing the statement solves the issue.
This used to work in 1.2.3.
--
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-5468) Prepared statements from default keyspace are broken
[
https://issues.apache.org/jira/browse/CASSANDRA-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-5468:
---
Summary: Prepared statements from default keyspace are broken (was:
Prepared statement from default keyspace are broken)
Prepared statements from default keyspace are broken
Key: CASSANDRA-5468
URL: https://issues.apache.org/jira/browse/CASSANDRA-5468
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.4
Environment: Windows 8 x64, java 1.7.0_11 x64
Reporter: Pierre Chalamet
Tested under CQL 3 binary protocol.
Preparing a statement from the default keyspace of the connection (statement
scoped with keyspace) and then running it will always throw the error no
keyspace has been specified.
{code}
Exec: CREATE KEYSPACE Tests WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 1}
Exec: CREATE TABLE Tests.AllTypes (a int, b int, primary key (a))
Prepare: insert into Tests.AllTypes (a, b) values (?, ?)
{code}
Exec prepared statement and exception no keyspace has been specified is
thrown.
Doing a use Tests before preparing the statement solves the issue.
This used to work in 1.2.3.
--
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-5164) Invalid streamId in cql binary protocol when using invalid CL
[ https://issues.apache.org/jira/browse/CASSANDRA-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Chalamet updated CASSANDRA-5164: --- Attachment: 5164-2.txt fix invalid cast Invalid streamId in cql binary protocol when using invalid CL - Key: CASSANDRA-5164 URL: https://issues.apache.org/jira/browse/CASSANDRA-5164 Project: Cassandra Issue Type: Bug Components: API Affects Versions: 1.2.0 Environment: Windows 8, java version 1.6.0_37 x86 Reporter: Pierre Chalamet Assignee: Sylvain Lebresne Priority: Minor Fix For: 1.2.4 Attachments: 5164-2.txt, 5164.txt Execute a query using invalid CL (0x100 for example) The response comes but does not use the request streamId (always 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-5164) Invalid streamId in cql binary protocol when using invalid CL
[
https://issues.apache.org/jira/browse/CASSANDRA-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614627#comment-13614627
]
Pierre Chalamet commented on CASSANDRA-5164:
The patch would be better by inverting lines 202 203 in ErrorMessage.java:
{code}
public static ErrorMessage fromException(Throwable e)
...
streamId = ((WrappedException)e).streamId;
e = e.getCause();
{code}
Otherwise, an invalid cast is raised. Patch enclosed - I've tested it and
exception nicely flows to the client using the right stream id.
Invalid streamId in cql binary protocol when using invalid CL
-
Key: CASSANDRA-5164
URL: https://issues.apache.org/jira/browse/CASSANDRA-5164
Project: Cassandra
Issue Type: Bug
Components: API
Affects Versions: 1.2.0
Environment: Windows 8, java version 1.6.0_37 x86
Reporter: Pierre Chalamet
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.4
Attachments: 5164-2.txt, 5164.txt
Execute a query using invalid CL (0x100 for example)
The response comes but does not use the request streamId (always 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-3783) Add 'null' support to CQL 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13591352#comment-13591352
]
Pierre Chalamet commented on CASSANDRA-3783:
Could the insert null command behaves like a batch mutation ? (Speaking
without knowing the code base anyway - sorry if this is totally dumb question).
I mean, it just need to coordinate (à la batch_mutate) insert (non null values)
and deletion (null values).
Could it be possible to split insert with null into 2 sub categories
(insertion and deletion) and just delegate to the internal batch_mutate handler
? This way, we do not care to have an internal representation for null values.
We just need the atomic mutation for insert/delete on same row, but this was
done before.
Add 'null' support to CQL 3.0
-
Key: CASSANDRA-3783
URL: https://issues.apache.org/jira/browse/CASSANDRA-3783
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Assignee: Michał Michalski
Priority: Minor
Labels: cql3
Fix For: 1.2.3
Attachments: 3783-v2.patch, 3783-wip-v1.patch
Dense composite supports adding records where only a prefix of all the
component specifying the key is defined. In other words, with:
{noformat}
CREATE TABLE connections (
userid int,
ip text,
port int,
protocol text,
time timestamp,
PRIMARY KEY (userid, ip, port, protocol)
) WITH COMPACT STORAGE
{noformat}
you can insert
{noformat}
INSERT INTO connections (userid, ip, port, time) VALUES (2, '192.168.0.1',
80, 123456789);
{noformat}
You cannot however select that column specifically (i.e, without selecting
column (2, '192.168.0.1', 80, 'http') for instance).
This ticket proposes to allow that though 'null', i.e. to allow
{noformat}
SELECT * FROM connections WHERE userid = 2 AND ip = '192.168.0.1' AND port =
80 AND protocol = null;
{noformat}
It would then also make sense to support:
{noformat}
INSERT INTO connections (userid, ip, port, protocol, time) VALUES (2,
'192.168.0.1', 80, null, 123456789);
{noformat}
as an equivalent to the insert query above.
--
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-3783) Add 'null' support to CQL 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580277#comment-13580277
]
Pierre Chalamet commented on CASSANDRA-3783:
Will this be supported for prepared statement as well ?
Add 'null' support to CQL 3.0
-
Key: CASSANDRA-3783
URL: https://issues.apache.org/jira/browse/CASSANDRA-3783
Project: Cassandra
Issue Type: Sub-task
Components: API
Reporter: Sylvain Lebresne
Priority: Minor
Labels: cql3
Fix For: 1.2.2
Attachments: 3783-wip-v1.patch
Dense composite supports adding records where only a prefix of all the
component specifying the key is defined. In other words, with:
{noformat}
CREATE TABLE connections (
userid int,
ip text,
port int,
protocol text,
time timestamp,
PRIMARY KEY (userid, ip, port, protocol)
) WITH COMPACT STORAGE
{noformat}
you can insert
{noformat}
INSERT INTO connections (userid, ip, port, time) VALUES (2, '192.168.0.1',
80, 123456789);
{noformat}
You cannot however select that column specifically (i.e, without selecting
column (2, '192.168.0.1', 80, 'http') for instance).
This ticket proposes to allow that though 'null', i.e. to allow
{noformat}
SELECT * FROM connections WHERE userid = 2 AND ip = '192.168.0.1' AND port =
80 AND protocol = null;
{noformat}
It would then also make sense to support:
{noformat}
INSERT INTO connections (userid, ip, port, protocol, time) VALUES (2,
'192.168.0.1', 80, null, 123456789);
{noformat}
as an equivalent to the insert query above.
--
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-5164) Invalid streamId in cql binary protocol when using invalid CL
Pierre Chalamet created CASSANDRA-5164: -- Summary: Invalid streamId in cql binary protocol when using invalid CL Key: CASSANDRA-5164 URL: https://issues.apache.org/jira/browse/CASSANDRA-5164 Project: Cassandra Issue Type: Bug Affects Versions: 1.2.0 Environment: Windows 8, java version 1.6.0_37 x86 Reporter: Pierre Chalamet Priority: Minor Execute a query using invalid CL (0x100 for example) The response comes but does not use the request streamId (always 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] [Created] (CASSANDRA-5121) system.peers.tokens is empty after node restart
Pierre Chalamet created CASSANDRA-5121:
--
Summary: system.peers.tokens is empty after node restart
Key: CASSANDRA-5121
URL: https://issues.apache.org/jira/browse/CASSANDRA-5121
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.0
Environment: Windows 8 / Java 1.6.0_37-b06
Reporter: Pierre Chalamet
Priority: Minor
Using a 2 nodes fresh cluster (127.0.0.1 127.0.0.2) running latest 1.2, I’m
querying system.peers to get the nodes of the cluster and their respective
token. But it seems there is a problem after either node restart.
When both node starts up, querying system.peers seems ok:
{code}
127.0.0.1 select * from system.peers;
+-+--+---+---+-+-+--+---+
| data_center | host_id | peer |
rack | release_version | rpc_address | schema_version
| tokens|
+=+==+===+===+=+=+==+===+
| datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | 127.0.0.2 |
rack1 | 1.2.0 | 127.0.0.2 |
59adb24e-f3cd-3e02-97f0-5b395827453f |
56713727820156410577229101238628035242|
+-+--+---+---+-+-+--+---+
{code}
But as soon as one node is restarted (let’s say 127.0.0.2), tokens column is
then empty:
{code}
127.0.0.1 select * from system.peers;
+-+--+---+---+-+-+--+-+
| data_center | host_id | peer |
rack | release_version | rpc_address | schema_version
| tokens |
+=+==+===+===+=+=+==+=+
| datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | 127.0.0.2 |
rack1 | 1.2.0 | 127.0.0.2 |
59adb24e-f3cd-3e02-97f0-5b395827453f | |
+-+--+---+---+-+-+--+-+
{code}
{code}
Log server side:
DEBUG 22:08:01,608 Responding: ROWS [peer(system, peers),
org.apache.cassandra.db.marshal.InetAddressType][data_center(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][host_id(system, peers),
org.apache.cassandra.db.marshal.UUIDType][rack(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][release_version(system, peers),
org.apache.cassandra.db.marshal.UTF8Type][rpc_address(system, peers),
org.apache.cassandra.db.marshal.InetAddressType][schema_version(system,
peers), org.apache.cassandra.db.marshal.UUIDType][tokens(system, peers),
org.apache.cassandra.db.marshal.SetType(org.apache.cassandra.db.marshal.UTF8Type)]
| 127.0.0.2 | datacenter1 | 4819cbb0-9741-4fe0-8d7d-95941b0247bf | rack1 |
1.2.0 | 127.0.0.2 | 59adb24e-f3cd-3e02-97f0-5b395827453f | null
{code}
Restarting the other node (127.0.0.1) restore back the tokens column.
--
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-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276521#comment-13276521
]
Pierre Chalamet commented on CASSANDRA-4242:
bq. Well, yes, it's definitely designed around data sources that give you
ordered values instead. This fits at the least JDBC, Python DBAPI, and Ruby
DBI. What are you using that can't work with this paradigm?
There are basically 2 use cases:
* micro-orm like (mapping object to and from a query)
* feeding from external data source (like a rowset which usually support
ordered and named columns).
Version in trunk of cassandra-sharp (my cassandra .net client) support actually
a micro-orm interface (with this patch) - it is still under development but
this will probably looks like this:
{code}
[Schema(TestKeyspace, Comment = People table, Name=People)]
public class PeopleSchema
{
[Index(Name = birthyear)]
public int Birthyear;
[Key(Name = firstname)]
public string FirstName;
[Column(Name = lastname)]
public string LastName;
}
cluster.CreatePeopleSchema();
cluster.Execute(insert into People (firstname, lastname, birthyear) values (?,
?, ?),
new {firstname = pierre, lastname = chalamet, birthyear =
1973});
{code}
I do not want this framework to be user driven (ie: the user provides the
parameters and knows the nitty gritty details of his query) - instead I want
this framework to be query driven for parameters feeding (ie: the query
determines what is necessary to complete the execution). This way, the user can
change its query without changing the parameters order - it is still the plain
old .net object exposing unordered properties. You can refactor as you want the
query or the .net object, it should still work.
The other interface I'd like to setup in the micro-orm area is something like
the on in Gigaspaces (query template with plain old object) - the interface is
really good for getting results. For extended queries, it is also required to
be able to map parameters.
The second use case is less obvious, but suppose I need to transfer data
between a database and C*.
I would select on one side and insert on the other side - using something like
a data reader in .net.
For that, I still do not want to rely on order of the column in the rowset - I
would prefer to discover the structure and bind parameters accordingly using a
the data reader metadata (basically column names).
I do believe it is good functionality client side. This will allow more way to
interact with C* in safer way without much cost anyway.
Compared to the cost of the i/o, retrieving the column names in
CqlPreparedResult and mapping client side is really cheap.
I've also read CASSANDRA-2474 - quite interesting thanks for the link. But I
really would prefer to have binary in column name instead of string. That's why
in the new patch I did not changed this. I'm not really clear on this, I had to
think more about it, but as is, I have the feeling that C* is moving away from
sliced query on binary column names (a strong feature in my opinion). It might
does stand when considering hadoop, hive and co... I might be the only guy
using C* alone anyway.
Moreover, CqlMetadata exposes column names as binary - I would also prefer
something symmetrical (weak argument anyway).
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242_3.txt
ensure compatibility with cql 3 client.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242_4.txt
Reverting to 2 lists in CqlPreparedResult
Column names are String now
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt, 4242_3.txt, 4242_4.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276071#comment-13276071
]
Pierre Chalamet commented on CASSANDRA-4242:
{quote}
But why would we need to? I thought the goal here is introspection of what a
prepared statement returns. Executing the statement works fine.
{quote}
I thought the cinematic was:
1/ prepare_cql_query
2/ execute_prepared_cql_query using parameters as specified by 1/
I just do not want to know the name of the parameters in CqlPreparedResult, I
need this to *bind* parameters from various data source (which expose unordered
named values).
The order of values is then really important from pov of the execution of query.
Am I missing something so ?
{quote}
Column names are always strings in CQL3. See
http://www.datastax.com/dev/blog/schema-in-cassandra-1-1 for a quick summary
and CASSANDRA-2474 for the gory details.
{quote}
Sorry, I should have read the spec first :-) But OK but I insist to have binary
values - it is more efficient that hex encoded strings.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242_2.txt
patch rebase from trunk
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276071#comment-13276071
]
Pierre Chalamet edited comment on CASSANDRA-4242 at 5/15/12 6:24 PM:
-
{quote}
But why would we need to? I thought the goal here is introspection of what a
prepared statement returns. Executing the statement works fine.
{quote}
I thought the cinematic was:
1/ prepare_cql_query
2/ execute_prepared_cql_query using parameters as specified by 1/
I just do not want to know the name of the parameters in CqlPreparedResult, I
need this to *bind* parameters from various data source (which expose unordered
named values).
The order of values is then really important from pov of the execution of query.
Am I missing something so ?
{quote}
Column names are always strings in CQL3. See
http://www.datastax.com/dev/blog/schema-in-cassandra-1-1 for a quick summary
and CASSANDRA-2474 for the gory details.
{quote}
Sorry, I should have read the spec first :-)
was (Author: pchalamet):
{quote}
But why would we need to? I thought the goal here is introspection of what a
prepared statement returns. Executing the statement works fine.
{quote}
I thought the cinematic was:
1/ prepare_cql_query
2/ execute_prepared_cql_query using parameters as specified by 1/
I just do not want to know the name of the parameters in CqlPreparedResult, I
need this to *bind* parameters from various data source (which expose unordered
named values).
The order of values is then really important from pov of the execution of query.
Am I missing something so ?
{quote}
Column names are always strings in CQL3. See
http://www.datastax.com/dev/blog/schema-in-cassandra-1-1 for a quick summary
and CASSANDRA-2474 for the gory details.
{quote}
Sorry, I should have read the spec first :-) But OK but I insist to have binary
values - it is more efficient that hex encoded strings.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276097#comment-13276097
]
Pierre Chalamet commented on CASSANDRA-4242:
Forget about my comment on hex encoded strings. Should read twice what I'm
writing.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt, 4242_2.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: (was: 4242.txt)
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional mapbinary,string name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242.txt
use list instead of map since the order is important
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional mapbinary,string name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Description:
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
was:
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional mapbinary,string name_types
}
{code}
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlNameType {
1: required binary key,
2: required string type
}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types,
4: optional listCqlNameType name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
Pierre Chalamet created CASSANDRA-4242:
--
Summary: Name of parameters should be available in
CqlPreparedResult
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional listbinary variable_names
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242.txt
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional listbinary variable_names
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: (was: 4242.txt)
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional listbinary variable_names
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Attachment: 4242.txt
using a map instead of 2 lists
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional listbinary variable_names
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4242) Name of parameters should be available in CqlPreparedResult
[
https://issues.apache.org/jira/browse/CASSANDRA-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4242:
---
Description:
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional mapbinary,string name_types
}
{code}
was:
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional listbinary variable_names
}
{code}
moved from two lists to one map.
Name of parameters should be available in CqlPreparedResult
---
Key: CASSANDRA-4242
URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Reporter: Pierre Chalamet
Priority: Minor
Attachments: 4242.txt
Client side, it could be nice to have the name of parameters in
CqlPreparedResult. This could allow parameters mapping by name instead of by
index.
{code}
struct CqlPreparedResult {
1: required i32 itemId,
2: required i32 count,
3: optional liststring variable_types
4: optional mapbinary,string name_types
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4210) Support for variadic parameters list for in clause in prepared cql query
Pierre Chalamet created CASSANDRA-4210:
--
Summary: Support for variadic parameters list for in clause in
prepared cql query
Key: CASSANDRA-4210
URL: https://issues.apache.org/jira/browse/CASSANDRA-4210
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.0
Environment: prepared cql queries
Reporter: Pierre Chalamet
Priority: Minor
This query
{code}
select * from Town where key in (?)
{code}
only allows one parameter for '?'.
This means querying for 'Paris' and 'London' can't be executed in one step with
this prepared statement.
Current workarounds are:
* either execute the prepared query 2 times with 'Paris' then 'London'
* or prepare a new query {{select * from Town where key in (?, ?)}} and bind
the 2 parameters
Having a support for variadic parameters list with in clause could improve
performance:
* single hop to get the data
* // fetching server side
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4201) Node crash after truncating CF
[
https://issues.apache.org/jira/browse/CASSANDRA-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265700#comment-13265700
]
Pierre Chalamet commented on CASSANDRA-4201:
Yes it is a 32 bits jvm running on x64 system.
Node crash after truncating CF
--
Key: CASSANDRA-4201
URL: https://issues.apache.org/jira/browse/CASSANDRA-4201
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: Windows 7 x64, 4Gb, JRE 1.6.0_31 (x86)
Reporter: Pierre Chalamet
Attachments: cassandra.yaml
1. Create a single node cluster, use default configuration, use cassandra.bat
to start the server:
2. run the following commands in cli:
{code}
create keyspace toto;
use toto;
create column family titi;
truncate titi;
{code}
3. the node dies with this error:
{code}
ERROR 23:23:02,118 Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Map failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:202)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:159)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(Unknown Source)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:119)
... 5 more
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
... 7 more
INFO 23:23:02,122 Stop listening to thrift clients
INFO 23:23:02,123 Waiting for messaging service to quiesce
INFO 23:23:02,125 MessagingService shutting down server thread.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4201) Node crash after truncating CF
[
https://issues.apache.org/jira/browse/CASSANDRA-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13265837#comment-13265837
]
Pierre Chalamet commented on CASSANDRA-4201:
1 gig. Using jvm options in cassandra.bat :
set JAVA_OPTS=-ea^
-javaagent:%CASSANDRA_HOME%\lib\jamm-0.2.5.jar^
-Xms1G^
-Xmx1G^
-XX:+HeapDumpOnOutOfMemoryError^
-XX:+UseParNewGC^
-XX:+UseConcMarkSweepGC^
-XX:+CMSParallelRemarkEnabled^
-XX:SurvivorRatio=8^
-XX:MaxTenuringThreshold=1^
-XX:CMSInitiatingOccupancyFraction=75^
-XX:+UseCMSInitiatingOccupancyOnly^
-Dcom.sun.management.jmxremote.port=7199^
-Dcom.sun.management.jmxremote.ssl=false^
-Dcom.sun.management.jmxremote.authenticate=false^
-Dlog4j.configuration=log4j-server.properties^
-Dlog4j.defaultInitOverride=true
Node crash after truncating CF
--
Key: CASSANDRA-4201
URL: https://issues.apache.org/jira/browse/CASSANDRA-4201
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: Windows 7 x64, 4Gb, JRE 1.6.0_31 (x86)
Reporter: Pierre Chalamet
Attachments: cassandra.yaml
1. Create a single node cluster, use default configuration, use cassandra.bat
to start the server:
2. run the following commands in cli:
{code}
create keyspace toto;
use toto;
create column family titi;
truncate titi;
{code}
3. the node dies with this error:
{code}
ERROR 23:23:02,118 Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Map failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:202)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:159)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(Unknown Source)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:119)
... 5 more
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
... 7 more
INFO 23:23:02,122 Stop listening to thrift clients
INFO 23:23:02,123 Waiting for messaging service to quiesce
INFO 23:23:02,125 MessagingService shutting down server thread.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-4201) Node crash after truncating CF
Pierre Chalamet created CASSANDRA-4201:
--
Summary: Node crash after truncating CF
Key: CASSANDRA-4201
URL: https://issues.apache.org/jira/browse/CASSANDRA-4201
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: Windows 7 x64, 4Gb, JRE 1.6.0_31 (x86)
Reporter: Pierre Chalamet
Attachments: cassandra.yaml
1. Create a single node cluster, use default configuration, use cassandra.bat
to start the server:
2. run the following commands in cli:
{code}
create keyspace toto;
use toto;
create column family titi;
truncate titi;
{code}
3. the node dies with this error:
{code}
ERROR 23:23:02,118 Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Map failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:202)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:159)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(Unknown Source)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:119)
... 5 more
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
... 7 more
INFO 23:23:02,122 Stop listening to thrift clients
INFO 23:23:02,123 Waiting for messaging service to quiesce
INFO 23:23:02,125 MessagingService shutting down server thread.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-4201) Node crash after truncating CF
[
https://issues.apache.org/jira/browse/CASSANDRA-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Chalamet updated CASSANDRA-4201:
---
Attachment: cassandra.yaml
Node crash after truncating CF
--
Key: CASSANDRA-4201
URL: https://issues.apache.org/jira/browse/CASSANDRA-4201
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Environment: Windows 7 x64, 4Gb, JRE 1.6.0_31 (x86)
Reporter: Pierre Chalamet
Attachments: cassandra.yaml
1. Create a single node cluster, use default configuration, use cassandra.bat
to start the server:
2. run the following commands in cli:
{code}
create keyspace toto;
use toto;
create column family titi;
truncate titi;
{code}
3. the node dies with this error:
{code}
ERROR 23:23:02,118 Exception in thread Thread[COMMIT-LOG-ALLOCATOR,5,main]
java.io.IOError: java.io.IOException: Map failed
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:127)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.recycle(CommitLogSegment.java:202)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$2.run(CommitLogAllocator.java:159)
at
org.apache.cassandra.db.commitlog.CommitLogAllocator$1.runMayThrow(CommitLogAllocator.java:95)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:30)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Map failed
at sun.nio.ch.FileChannelImpl.map(Unknown Source)
at
org.apache.cassandra.db.commitlog.CommitLogSegment.init(CommitLogSegment.java:119)
... 5 more
Caused by: java.lang.OutOfMemoryError: Map failed
at sun.nio.ch.FileChannelImpl.map0(Native Method)
... 7 more
INFO 23:23:02,122 Stop listening to thrift clients
INFO 23:23:02,123 Waiting for messaging service to quiesce
INFO 23:23:02,125 MessagingService shutting down server thread.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
