[jira] [Commented] (CASSANDRA-3078) Make Secondary Indexes Pluggable
[
https://issues.apache.org/jira/browse/CASSANDRA-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092280#comment-13092280
]
T Jake Luciani commented on CASSANDRA-3078:
---
bq. Otherwise you're essentially forced to take downtime to upgrade your app at
the same time as your database, and that's not acceptable for almost all our
users.
My concern is confusion around multiple ways of creating indexes long-term. So
perhaps we try to utilize index_type so it keeps being the way to index
columns. One idea is we remove index_class add a CUSTOM index_type, that would
require specifying the classname as a index_option.
{code}
{
index_type: CUSTOM
index_options: {
class_name: o.a.c.d.MyIndexType
}
}
{code}
Make Secondary Indexes Pluggable
-
Key: CASSANDRA-3078
URL: https://issues.apache.org/jira/browse/CASSANDRA-3078
Project: Cassandra
Issue Type: Improvement
Components: Core
Affects Versions: 1.0
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Labels: secondary_index
Fix For: 1.0
Attachments: v1-0001-CASSANDRA-3078-pluggable-secondary-indexes.txt,
v1-0002-CASSANDRA-3078-pluggable-secondary-index-thrift.txt
CASSANDRA-2982 got us most of the way there...
This ticket removes the IndexType enum (while keeping support for KEYS
internally from old cf metadata).
You now specify a index_class rather than index_type. index_class is the
full classname of the SecondaryIndex impl. This also adds a index_options
map to pass extra info to the secondary index impl if needed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3025) PHP/PDO driver for Cassandra CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092287#comment-13092287
]
Mikko Koppanen commented on CASSANDRA-3025:
---
bq. I don't understand the problem, can you elaborate?
This waa the same problem that I mentioned in the first sentence.
I committed large amount improvements today
(https://github.com/mkoppanen/php-pdo_cassandra/commit/8e37cb05c73eb96c52e87d6a722d66cceeff6f0b):
https://github.com/mkoppanen/php-pdo_cassandra/blob/master/tests/017-sparsecolumns.phpt
Changed the result set to use union as you suggested. I ran into a problem
where same statement can return different amount of columns between different
executions but got it sorted out. That scenario is tested at the end of the
test.
https://github.com/mkoppanen/php-pdo_cassandra/blob/master/tests/021-comparators.phpt
Sparse columns now work with integer keys as well.
PHP/PDO driver for Cassandra CQL
Key: CASSANDRA-3025
URL: https://issues.apache.org/jira/browse/CASSANDRA-3025
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Mikko Koppanen
Labels: php
Attachments: pdo_cassandra-0.1.0.tgz, pdo_cassandra-0.1.1.tgz,
pdo_cassandra-0.1.2.tgz, php_test_results_20110818_2317.txt
Hello,
attached is the initial version of the PDO driver for Cassandra CQL language.
This is a native PHP extension written in what I would call a combination of
C and C++, due to PHP being C. The thrift API used is the C++.
The API looks roughly following:
{code}
?php
$db = new PDO('cassandra:host=127.0.0.1;port=9160');
$db-exec (CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;);
$db-exec (USE mytest);
$db-exec (CREATE COLUMNFAMILY users (
my_key varchar PRIMARY KEY,
full_name varchar ););
$stmt = $db-prepare (INSERT INTO users (my_key, full_name) VALUES (:key,
:full_name););
$stmt-execute (array (':key' = 'mikko', ':full_name' = 'Mikko K' ));
{code}
Currently prepared statements are emulated on the client side but I
understand that there is a plan to add prepared statements to Cassandra CQL
API as well. I will add this feature in to the extension as soon as they are
implemented.
Additional documentation can be found in github
https://github.com/mkoppanen/php-pdo_cassandra, in the form of rendered
MarkDown file. Tests are currently not included in the package file and they
can be found in the github for now as well.
I have created documentation in docbook format as well, but have not yet
rendered it.
Comments and feedback are welcome.
Thanks,
Mikko
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2883) Add Support for BigDecimal Java data type as the NumericType AbstractType
[
https://issues.apache.org/jira/browse/CASSANDRA-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw reassigned CASSANDRA-2883:
Assignee: Rick Shaw
Add Support for BigDecimal Java data type as the NumericType AbstractType
---
Key: CASSANDRA-2883
URL: https://issues.apache.org/jira/browse/CASSANDRA-2883
Project: Cassandra
Issue Type: Sub-task
Components: Core
Affects Versions: 0.8.1
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: CQL, JDBC,, lhf
Fix For: 0.8.5
The JDBC Driver suite needs support for {{BigDecimal}} to complete it's data
type support for {{ResultSet}} and {{PreparedStatement}}. This datatype could
also be used to represent numeric (non-integer) counter values. This is a
very simple addition to the collection of data types supported by Cassandra.
It is quite versatile like {{BigInteger}}. It can represent decimal numbers
of virtually any precision and scale. It is represented in Java as an
arbitrary precision integer unscaled value ( think {{IntegerType}} )and a
32-bit integer scale factor, which could be represented as a {{IntegerType}}
as well. This could share much of the logic from the {{BigInteger}}
({{IntegerType}}) implementation.
CQL would need to add a datatype (numeric?). Decimal literal support is
already provided in CQL.
This is low hanging fruit.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3025) PHP/PDO driver for Cassandra CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092298#comment-13092298
]
Mikko Koppanen commented on CASSANDRA-3025:
---
Hi again,
added test for counters:
https://github.com/mkoppanen/php-pdo_cassandra/blob/master/tests/022-counters.phpt
PHP/PDO driver for Cassandra CQL
Key: CASSANDRA-3025
URL: https://issues.apache.org/jira/browse/CASSANDRA-3025
Project: Cassandra
Issue Type: New Feature
Components: API
Reporter: Mikko Koppanen
Labels: php
Attachments: pdo_cassandra-0.1.0.tgz, pdo_cassandra-0.1.1.tgz,
pdo_cassandra-0.1.2.tgz, php_test_results_20110818_2317.txt
Hello,
attached is the initial version of the PDO driver for Cassandra CQL language.
This is a native PHP extension written in what I would call a combination of
C and C++, due to PHP being C. The thrift API used is the C++.
The API looks roughly following:
{code}
?php
$db = new PDO('cassandra:host=127.0.0.1;port=9160');
$db-exec (CREATE KEYSPACE mytest with strategy_class = 'SimpleStrategy' and
strategy_options:replication_factor=1;);
$db-exec (USE mytest);
$db-exec (CREATE COLUMNFAMILY users (
my_key varchar PRIMARY KEY,
full_name varchar ););
$stmt = $db-prepare (INSERT INTO users (my_key, full_name) VALUES (:key,
:full_name););
$stmt-execute (array (':key' = 'mikko', ':full_name' = 'Mikko K' ));
{code}
Currently prepared statements are emulated on the client side but I
understand that there is a plan to add prepared statements to Cassandra CQL
API as well. I will add this feature in to the extension as soon as they are
implemented.
Additional documentation can be found in github
https://github.com/mkoppanen/php-pdo_cassandra, in the form of rendered
MarkDown file. Tests are currently not included in the package file and they
can be found in the github for now as well.
I have created documentation in docbook format as well, but have not yet
rendered it.
Comments and feedback are welcome.
Thanks,
Mikko
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3081) Cassandra cli strategy options should be a hash not an array of hashes
[
https://issues.apache.org/jira/browse/CASSANDRA-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092321#comment-13092321
]
Eric Evans commented on CASSANDRA-3081:
---
Is this going to break people's existing scripts?
Cassandra cli strategy options should be a hash not an array of hashes
--
Key: CASSANDRA-3081
URL: https://issues.apache.org/jira/browse/CASSANDRA-3081
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Minor
Fix For: 1.0
Attachments: 0001-CASSANDRA-3081-fix-indentation.txt,
0002-CASSANDRA-3081-switch-to-hashes.txt
Currently strategy options are specified as an array of hashes:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:4}];
{code}
this should be:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = {replication_factor:4};
{code}
Also, for column_metadata we need sub hashes for CASSANDRA-3078
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3081) Cassandra cli strategy options should be a hash not an array of hashes
[
https://issues.apache.org/jira/browse/CASSANDRA-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092323#comment-13092323
]
Pavel Yaskevich commented on CASSANDRA-3081:
Yes, it is.
Cassandra cli strategy options should be a hash not an array of hashes
--
Key: CASSANDRA-3081
URL: https://issues.apache.org/jira/browse/CASSANDRA-3081
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Minor
Fix For: 1.0
Attachments: 0001-CASSANDRA-3081-fix-indentation.txt,
0002-CASSANDRA-3081-switch-to-hashes.txt
Currently strategy options are specified as an array of hashes:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:4}];
{code}
this should be:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = {replication_factor:4};
{code}
Also, for column_metadata we need sub hashes for CASSANDRA-3078
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092324#comment-13092324
]
Rick Shaw commented on CASSANDRA-3089:
--
The JDBC {{RowId}} assumes it can be compared with another {{RowId}} for
identity. The stated specification says that they are the same if they have the
same logical/physical identity and they come from the same Table and Dataset.
This implies the same CF and KS as well as the matching row index value. To
illustrate: if a rows in two CFs A, and B had {{Integer}} indexes, it could
easily happen that both CFs had a row with the index value of integer 1. But a
{{RowId}} from CF A containing 1 and a {{RowId}} containing 1 from CF B
should not report being equal because they come from different CFs.
However it is not common practice to store the CF and the KS along with a row
index when creating secondary indexes either ad-hoc or through C* internal
tooling. The KS can be implied as the current KS because it is not useful in C*
for it to be anything but the current KS, although I guess it is _possible_ as
well. But the CF can not really be known unless we create a new {{RowIdType}},
and that seems like it would never really be used in common practice anyway.
The alternative is to document that we do not really comply, and just use
equality of the byte value contents of the contained in the column's value.
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3081) Cassandra cli strategy options should be a hash not an array of hashes
[
https://issues.apache.org/jira/browse/CASSANDRA-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092327#comment-13092327
]
Eric Evans commented on CASSANDRA-3081:
---
Awesome.
Cassandra cli strategy options should be a hash not an array of hashes
--
Key: CASSANDRA-3081
URL: https://issues.apache.org/jira/browse/CASSANDRA-3081
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Minor
Fix For: 1.0
Attachments: 0001-CASSANDRA-3081-fix-indentation.txt,
0002-CASSANDRA-3081-switch-to-hashes.txt
Currently strategy options are specified as an array of hashes:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:4}];
{code}
this should be:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = {replication_factor:4};
{code}
Also, for column_metadata we need sub hashes for CASSANDRA-3078
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3081) Cassandra cli strategy options should be a hash not an array of hashes
[
https://issues.apache.org/jira/browse/CASSANDRA-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092328#comment-13092328
]
Jonathan Ellis commented on CASSANDRA-3081:
---
IMO that's okay as long as you add a note to NEWS.
Cassandra cli strategy options should be a hash not an array of hashes
--
Key: CASSANDRA-3081
URL: https://issues.apache.org/jira/browse/CASSANDRA-3081
Project: Cassandra
Issue Type: Improvement
Components: Tools
Reporter: T Jake Luciani
Assignee: T Jake Luciani
Priority: Minor
Fix For: 1.0
Attachments: 0001-CASSANDRA-3081-fix-indentation.txt,
0002-CASSANDRA-3081-switch-to-hashes.txt
Currently strategy options are specified as an array of hashes:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = [{replication_factor:4}];
{code}
this should be:
{code}
create keyspace Keyspace2
with placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy'
and strategy_options = {replication_factor:4};
{code}
Also, for column_metadata we need sub hashes for CASSANDRA-3078
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3089) Support RowId in ResultSet
[
https://issues.apache.org/jira/browse/CASSANDRA-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092329#comment-13092329
]
Jonathan Ellis commented on CASSANDRA-3089:
---
I checked what postgresql does:
{code}
public RowId getRowId(int parameterIndex) throws SQLException
{
throw org.postgresql.Driver.notImplemented(this.getClass(),
getRowId(int));
}
public RowId getRowId(String parameterName) throws SQLException
{
throw org.postgresql.Driver.notImplemented(this.getClass(),
getRowId(String));
}
{code}
So, I'd say using byte value and documenting that it's not technically
compliant with the spec is reasonable. :)
Support RowId in ResultSet
--
Key: CASSANDRA-3089
URL: https://issues.apache.org/jira/browse/CASSANDRA-3089
Project: Cassandra
Issue Type: Sub-task
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Trivial
Labels: JDBC, lhf
Fix For: 1.0
Support the JDBC concept of {{RowId}} by using the C* row index value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2775) ant build-test is failing with 0.8.0
[ https://issues.apache.org/jira/browse/CASSANDRA-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092330#comment-13092330 ] Vivek Mishra commented on CASSANDRA-2775: - This is working fine now with current trunk code base. ant build-test is failing with 0.8.0 Key: CASSANDRA-2775 URL: https://issues.apache.org/jira/browse/CASSANDRA-2775 Project: Cassandra Issue Type: Bug Components: Tests Affects Versions: 0.8.0 Reporter: Vivek Mishra Assignee: Vivek Mishra Priority: Minor Attachments: build.xml Steps to reproduce: 1) ant clean build 2) ant build-test It is failing for : build-test: [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\build.xml:975: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set [javac] Compiling 124 source files to C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\build\test\classes [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:357: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] CassandraPreparedStatement stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac] ^ [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:357: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] CassandraPreparedStatement stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac]^ [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:365: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac] ^ [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:377: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 4 errors -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3078) Make Secondary Indexes Pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092337#comment-13092337 ] Pavel Yaskevich edited comment on CASSANDRA-3078 at 8/27/11 5:58 PM: - bq. One idea is we remove index_class add a CUSTOM index_type, that would require specifying the classname as a index_option. +1, we'll have index_options so we don't we just put index_class in there and leave index_type for compatibility. was (Author: xedin): bq. One idea is we remove index_class add a CUSTOM index_type, that would require specifying the classname as a index_option. +1, we have index_options so we don't we just put index_class in there and leave index_type for compatibility. Make Secondary Indexes Pluggable - Key: CASSANDRA-3078 URL: https://issues.apache.org/jira/browse/CASSANDRA-3078 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0 Reporter: T Jake Luciani Assignee: T Jake Luciani Labels: secondary_index Fix For: 1.0 Attachments: v1-0001-CASSANDRA-3078-pluggable-secondary-indexes.txt, v1-0002-CASSANDRA-3078-pluggable-secondary-index-thrift.txt CASSANDRA-2982 got us most of the way there... This ticket removes the IndexType enum (while keeping support for KEYS internally from old cf metadata). You now specify a index_class rather than index_type. index_class is the full classname of the SecondaryIndex impl. This also adds a index_options map to pass extra info to the secondary index impl if needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3078) Make Secondary Indexes Pluggable
[ https://issues.apache.org/jira/browse/CASSANDRA-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092337#comment-13092337 ] Pavel Yaskevich commented on CASSANDRA-3078: bq. One idea is we remove index_class add a CUSTOM index_type, that would require specifying the classname as a index_option. +1, we have index_options so we don't we just put index_class in there and leave index_type for compatibility. Make Secondary Indexes Pluggable - Key: CASSANDRA-3078 URL: https://issues.apache.org/jira/browse/CASSANDRA-3078 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 1.0 Reporter: T Jake Luciani Assignee: T Jake Luciani Labels: secondary_index Fix For: 1.0 Attachments: v1-0001-CASSANDRA-3078-pluggable-secondary-indexes.txt, v1-0002-CASSANDRA-3078-pluggable-secondary-index-thrift.txt CASSANDRA-2982 got us most of the way there... This ticket removes the IndexType enum (while keeping support for KEYS internally from old cf metadata). You now specify a index_class rather than index_type. index_class is the full classname of the SecondaryIndex impl. This also adds a index_options map to pass extra info to the secondary index impl if needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2775) ant build-test is failing with 0.8.0
[ https://issues.apache.org/jira/browse/CASSANDRA-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis resolved CASSANDRA-2775. --- Resolution: Not A Problem Assignee: (was: Vivek Mishra) ant build-test is failing with 0.8.0 Key: CASSANDRA-2775 URL: https://issues.apache.org/jira/browse/CASSANDRA-2775 Project: Cassandra Issue Type: Bug Components: Tests Affects Versions: 0.8.0 Reporter: Vivek Mishra Priority: Minor Attachments: build.xml Steps to reproduce: 1) ant clean build 2) ant build-test It is failing for : build-test: [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\build.xml:975: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set [javac] Compiling 124 source files to C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\build\test\classes [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:357: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] CassandraPreparedStatement stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac] ^ [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:357: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] CassandraPreparedStatement stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac]^ [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:365: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac] ^ [javac] C:\vivek\apache-cassandra-0.8.0-src\apache-cassandra-0.8.0-src\drivers\java\test\org\apache\cassandra\cql\jdbc\PreparedStatementTest.java:377: cannot find symbol [javac] symbol : class CassandraPreparedStatement [javac] location: class org.apache.cassandra.cql.jdbc.PreparedStatementTest [javac] stmt = (CassandraPreparedStatement)con.prepareStatement(q); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 4 errors -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3090) NPE while get_range_slices
NPE while get_range_slices
--
Key: CASSANDRA-3090
URL: https://issues.apache.org/jira/browse/CASSANDRA-3090
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.1
Reporter: Evgeny Ryabitskiy
We have 4 node Cassandra (version 0.8.1) cluster. 2 CF inside. While first CF
is working properly (read/store), get_range_slices query on second CF return
Internal error.
{code}
ERROR [pool-2-thread-51] 2011-08-25 15:02:04,360 Cassandra.java (line 3210)
Internal error processing get_range_slices
java.lang.NullPointerException
at org.apache.cassandra.db.ColumnFamily.diff(ColumnFamily.java:298)
at org.apache.cassandra.db.ColumnFamily.diff(ColumnFamily.java:406)
at
org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:103)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:120)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:85)
at
org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:74)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:715)
at
org.apache.cassandra.thrift.CassandraServer.get_range_slices(CassandraServer.java:617)
at
org.apache.cassandra.thrift.Cassandra$Processor$get_range_slices.process(Cassandra.java:3202)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2973) fatal errrors after nodetool cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073237#comment-13073237 ] Wojciech Meler edited comment on CASSANDRA-2973 at 8/27/11 11:12 PM: - Scrub log from 9th node 2011-07-30 21:39:55:386 CEST INFO [CompactionExecutor:172][org.apache.cassandra.db.compaction.CompactionManager] Scrubbing SSTableReader(path='/var/lib/cassandra/data/mail/mta_logs-g-733-Data.db') 2011-07-30 21:39:55:469 CEST WARN [CompactionExecutor:172][org.apache.cassandra.db.compaction.CompactionManager] Non-fatal error reading row (stacktrace follows) java.io.IOError: java.io.IOException: Impossible row size 7933455022436196 at org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:719) at org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:633) at org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:65) at org.apache.cassandra.db.compaction.CompactionManager$3.call(CompactionManager.java:250) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: Impossible row size 7933455022436196 ... 9 more 2011-07-30 21:39:55:470 CEST INFO [CompactionExecutor:172][org.apache.cassandra.db.compaction.CompactionManager] Retrying from row index; data is -8 bytes starting at 547199 2011-07-30 21:39:55:470 CEST WARN [CompactionExecutor:172][org.apache.cassandra.db.compaction.CompactionManager] Retry failed too. Skipping to next row (retry's stacktrace follows) java.io.IOError: java.io.EOFException: bloom filter claims to be 909194543 bytes, longer than entire row size -8 at org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:149) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:90) at org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:748) at org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:633) at org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:65) at org.apache.cassandra.db.compaction.CompactionManager$3.call(CompactionManager.java:250) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: bloom filter claims to be 909194543 bytes, longer than entire row size -8 at org.apache.cassandra.io.sstable.IndexHelper.defreezeBloomFilter(IndexHelper.java:111) at org.apache.cassandra.io.sstable.SSTableIdentityIterator.init(SSTableIdentityIterator.java:119) ... 10 more 2011-07-30 21:39:55:482 CEST WARN [CompactionExecutor:172][org.apache.cassandra.db.compaction.CompactionManager] Non-fatal error reading row (stacktrace follows) was (Author: wmeler): Scrub log from 9th node 2011-07-30 21:39:55:386 CEST INFO [CompactionExecutor:172][org.apache.cassandra.db.compaction.CompactionManager] Scrubbing SSTableReader(path='/var/lib/cassandra/data/mail/mta_logs-g-733-Data.db') 2011-07-30 21:39:55:469 CEST WARN [CompactionExecutor:172][org.apache.cassandra.db.compaction.CompactionManager] Non-fatal error reading row (stacktrace follows) java.io.IOError: java.io.IOException: Impossible row size 7933455022436196 at org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:719) at org.apache.cassandra.db.compaction.CompactionManager.doScrub(CompactionManager.java:633) at org.apache.cassandra.db.compaction.CompactionManager.access$600(CompactionManager.java:65) at org.apache.cassandra.db.compaction.CompactionManager$3.call(CompactionManager.java:250) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: Impossible row size 7933455022436196 ... 9 more 2011-07-30
[jira] [Updated] (CASSANDRA-3075) Cassandra CLI unable to use list command with INTEGER column names, resulting in syntax error
[ https://issues.apache.org/jira/browse/CASSANDRA-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Yaskevich updated CASSANDRA-3075: --- Attachment: CASSANDRA-3075.patch Made column family (and keyspace) support integer representation in all statements (create/update/set/get/list/drop/drop index/truncate/assume), only one limitation in here - when you use drop index on cf.column command if cf is numeric it should be put in quotes. Tests are updated to check if everything works correctly. Rebased with cassandra-0.8 branch (last commit d9091c5aa88927ee2daa31ec69d865946b975fd9) Cassandra CLI unable to use list command with INTEGER column names, resulting in syntax error - Key: CASSANDRA-3075 URL: https://issues.apache.org/jira/browse/CASSANDRA-3075 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.0 Environment: 64 Bit Ubuntu 11.04(full update), AMD64 + 8GB RAM + 500GB Hdd, Java 1.6.0_26, Cassandra 0.8.0 + 4GB heap, Cassandra CLI Reporter: Renato Bacelar da Silveira Assignee: Pavel Yaskevich Priority: Minor Labels: features, newbie Fix For: 0.8.5 Attachments: CASSANDRA-3075.patch I have a Column Family named 1105115. I have inserted the CF with Hector, and it did not throw any exception concerning the name of the column. If I am issuing the command list 1105115; I incur the following error: [default@unknown] list 1105115; Syntax error at position 5: mismatched input '1105115' expecting Identifier I presume we are not to name CFs as integers? Or is there something I am missing from the bellow help content: [default@unknown] help list; list cf; list cf[startKey:]; list cf[startKey:endKey]; list cf[startKey:endKey] limit limit; List a range of rows, and all of their columns, in the specified column family. The order of rows returned is dependant on the Partitioner in use. Required Parameters: - cf: Name of the column family to list rows from. Optional Parameters: - endKey: Key to end the range at. The end key will be included in the result. Defaults to an empty byte array. - limit: Number of rows to return. Default is 100. - startKey: Key start the range from. The start key will be included in the result. Defaults to an empty byte array. Examples: list Standard1; list Super1[j:]; list Standard1[j:k] limit 40; Column Family Info: ColumnFamily: 1105115 Key Validation Class: org.apache.cassandra.db.marshal.BytesType Default column value validator: org.apache.cassandra.db.marshal.BytesType Columns sorted by: org.apache.cassandra.db.marshal.AsciiType Row cache size / save period in seconds: 0.0/0 Key cache size / save period in seconds: 20.0/14400 Memtable thresholds: 0.5203125/111/1440 (millions of ops/MB/minutes) GC grace seconds: 864000 Compaction min/max thresholds: 4/32 Read repair chance: 1.0 Replicate on write: true Built indexes: [] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2973) fatal errrors after nodetool cleanup
[ https://issues.apache.org/jira/browse/CASSANDRA-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092394#comment-13092394 ] Wojciech Meler commented on CASSANDRA-2973: --- I've examined log files and found one broken sstable for which I have pre-cleanup and pre-scrub snapshots. It's too big for test case (8GB). I'll try to isolate the problem. fatal errrors after nodetool cleanup Key: CASSANDRA-2973 URL: https://issues.apache.org/jira/browse/CASSANDRA-2973 Project: Cassandra Issue Type: Bug Affects Versions: 0.8.1 Reporter: Wojciech Meler Assignee: Sylvain Lebresne after adding nodes to cluster running cleanup I get scaring exceptions in log: 2011-07-30 00:00:05:506 CEST ERROR [ReadStage:2335][org.apache.cassandra.service.AbstractCassandraDaemon] Fatal exception in thread Thread[ReadStage:2335,5,main] java.io.IOError: java.io.IOException: mmap segment underflow; remaining is 4394 but 60165 requested at org.apache.cassandra.db.columniterator.IndexedSliceReader.init(IndexedSliceReader.java:80) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:91) at org.apache.cassandra.db.columniterator.SSTableSliceIterator.init(SSTableSliceIterator.java:67) at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:66) at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:80) at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1292) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1189) at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1146) at org.apache.cassandra.db.Table.getRow(Table.java:385) at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:61) at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:69) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: mmap segment underflow; remaining is 4394 but 60165 requested at org.apache.cassandra.io.util.MappedFileDataInput.readBytes(MappedFileDataInput.java:117) at org.apache.cassandra.utils.ByteBufferUtil.read(ByteBufferUtil.java:389) at org.apache.cassandra.utils.ByteBufferUtil.readWithShortLength(ByteBufferUtil.java:368) at org.apache.cassandra.io.sstable.IndexHelper$IndexInfo.deserialize(IndexHelper.java:194) at org.apache.cassandra.io.sstable.IndexHelper.deserializeIndex(IndexHelper.java:83) at org.apache.cassandra.db.columniterator.IndexedSliceReader.init(IndexedSliceReader.java:73) ... 14 more exceptions disappeared after running scrub -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Fix For: 0.8.5
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen to
be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3091) Move the caching of KS and CF metadata in the JDBC suite from Connection to Statement
[
https://issues.apache.org/jira/browse/CASSANDRA-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Shaw updated CASSANDRA-3091:
-
Attachment: move-metadata-for decoder-to-statement-level-v1.txt
Move the caching of KS and CF metadata in the JDBC suite from Connection to
Statement
-
Key: CASSANDRA-3091
URL: https://issues.apache.org/jira/browse/CASSANDRA-3091
Project: Cassandra
Issue Type: Improvement
Components: Drivers
Affects Versions: 0.8.4
Reporter: Rick Shaw
Assignee: Rick Shaw
Priority: Minor
Labels: JDBC
Fix For: 0.8.5
Attachments: move-metadata-for decoder-to-statement-level-v1.txt
Currently, all caching of metadata used in JDBC's {{ColumnDecoder}} class is
loaded and held in the {{CassandraConnection}} class. The implication of this
is that any activity on the connected server from the time the connection is
established is not reflected in the KSs and CF that can be accessed by the
{{ResultSet, Statement}} and {{PreparedStatement}}.
By moving the cached metadata to the {{Statement}} level, the currency of the
metadata can be checked within the {{Statement}} and reloaded if it is seen
to be absent. And by instantiating a new {{Statement}} (on any existing
connection) you are assured of getting the most current copy of the metadata
known to the server at the new time of instantiation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3075) Cassandra CLI unable to use list command with INTEGER column names, resulting in syntax error
[ https://issues.apache.org/jira/browse/CASSANDRA-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092420#comment-13092420 ] Jonathan Ellis commented on CASSANDRA-3075: --- +1 Cassandra CLI unable to use list command with INTEGER column names, resulting in syntax error - Key: CASSANDRA-3075 URL: https://issues.apache.org/jira/browse/CASSANDRA-3075 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.8.0 Environment: 64 Bit Ubuntu 11.04(full update), AMD64 + 8GB RAM + 500GB Hdd, Java 1.6.0_26, Cassandra 0.8.0 + 4GB heap, Cassandra CLI Reporter: Renato Bacelar da Silveira Assignee: Pavel Yaskevich Priority: Minor Labels: features, newbie Fix For: 0.8.5 Attachments: CASSANDRA-3075.patch I have a Column Family named 1105115. I have inserted the CF with Hector, and it did not throw any exception concerning the name of the column. If I am issuing the command list 1105115; I incur the following error: [default@unknown] list 1105115; Syntax error at position 5: mismatched input '1105115' expecting Identifier I presume we are not to name CFs as integers? Or is there something I am missing from the bellow help content: [default@unknown] help list; list cf; list cf[startKey:]; list cf[startKey:endKey]; list cf[startKey:endKey] limit limit; List a range of rows, and all of their columns, in the specified column family. The order of rows returned is dependant on the Partitioner in use. Required Parameters: - cf: Name of the column family to list rows from. Optional Parameters: - endKey: Key to end the range at. The end key will be included in the result. Defaults to an empty byte array. - limit: Number of rows to return. Default is 100. - startKey: Key start the range from. The start key will be included in the result. Defaults to an empty byte array. Examples: list Standard1; list Super1[j:]; list Standard1[j:k] limit 40; Column Family Info: ColumnFamily: 1105115 Key Validation Class: org.apache.cassandra.db.marshal.BytesType Default column value validator: org.apache.cassandra.db.marshal.BytesType Columns sorted by: org.apache.cassandra.db.marshal.AsciiType Row cache size / save period in seconds: 0.0/0 Key cache size / save period in seconds: 20.0/14400 Memtable thresholds: 0.5203125/111/1440 (millions of ops/MB/minutes) GC grace seconds: 864000 Compaction min/max thresholds: 4/32 Read repair chance: 1.0 Replicate on write: true Built indexes: [] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3090) NPE while get_range_slices
[
https://issues.apache.org/jira/browse/CASSANDRA-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-3090.
---
Resolution: Duplicate
This was fixed in CASSANDRA-2823. Generally speaking, it will save time to
upgrade before filing bug reports because there's a good chance it's already
fixed.
NPE while get_range_slices
--
Key: CASSANDRA-3090
URL: https://issues.apache.org/jira/browse/CASSANDRA-3090
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.1
Reporter: Evgeny Ryabitskiy
We have 4 node Cassandra (version 0.8.1) cluster. 2 CF inside. While first CF
is working properly (read/store), get_range_slices query on second CF return
Internal error.
{code}
ERROR [pool-2-thread-51] 2011-08-25 15:02:04,360 Cassandra.java (line 3210)
Internal error processing get_range_slices
java.lang.NullPointerException
at org.apache.cassandra.db.ColumnFamily.diff(ColumnFamily.java:298)
at org.apache.cassandra.db.ColumnFamily.diff(ColumnFamily.java:406)
at
org.apache.cassandra.service.RowRepairResolver.maybeScheduleRepairs(RowRepairResolver.java:103)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:120)
at
org.apache.cassandra.service.RangeSliceResponseResolver$2.getReduced(RangeSliceResponseResolver.java:85)
at
org.apache.cassandra.utils.ReducingIterator.computeNext(ReducingIterator.java:74)
at
com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:140)
at
com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:135)
at
org.apache.cassandra.service.StorageProxy.getRangeSlice(StorageProxy.java:715)
at
org.apache.cassandra.thrift.CassandraServer.get_range_slices(CassandraServer.java:617)
at
org.apache.cassandra.thrift.Cassandra$Processor$get_range_slices.process(Cassandra.java:3202)
at
org.apache.cassandra.thrift.Cassandra$Processor.process(Cassandra.java:2889)
at
org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:187)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
