[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057659#comment-13057659 ] Mck SembWever commented on CASSANDRA-2388: -- Then i would hope for two separate InputFormats. One optimised for local node connection, where cassandra is deemed the more important system over hadoop, and another where data can be read in from anywhere. I think the latter should be supported in some manner since users may not always have the possibility to install hadoop and cassandra on the same servers, or they might not think it to be so critical part (eg if CFIF is reading using a IndexClause the input data set might be quite small and the remaining code in the m/r be the bulk of the processing...) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.7.6, 0.8.0 Reporter: Eldon Stegall Assignee: Jeremy Hanna Labels: hadoop, inputformat Fix For: 0.7.7, 0.8.2 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057707#comment-13057707 ] Hartog C. de Mik commented on CASSANDRA-2500: - Is this code available under version-control somewhere? Would love to review/collaborate (when time permits) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Components: API Reporter: Jon Hermes Assignee: Pavel Yaskevich Labels: cql Fix For: 0.8.2 Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2045) Simplify HH to decrease read load when nodes come back
[ https://issues.apache.org/jira/browse/CASSANDRA-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057731#comment-13057731 ] Nicholas Telford commented on CASSANDRA-2045: - Since we're now deserializing the RowMutation we find for a hint, we're going to need to start at least ensuring the version matches MessagingService.version_. At the moment, this is done by HHOM, but I'd feel more comfortable having it in RowMutationSerializer.deserialize(). What would be preferable here? I was thinking of throwing an Exception in deserialize, but I'm concerned about other callers not handling it properly. Simplify HH to decrease read load when nodes come back -- Key: CASSANDRA-2045 URL: https://issues.apache.org/jira/browse/CASSANDRA-2045 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Nicholas Telford Fix For: 1.0 Attachments: 0001-Changed-storage-of-Hints-to-store-a-serialized-RowMu.patch, 0002-Refactored-HintedHandoffManager.sendRow-to-reduce-co.patch, 0003-Fixed-some-coding-style-issues.patch, 0004-Fixed-direct-usage-of-Gossiper.getEndpointStateForEn.patch, 0005-Removed-duplicate-failure-detection-conditionals.-It.patch, 0006-Removed-handling-of-old-style-hints.patch, 2045-v3.txt, CASSANDRA-2045-simplify-hinted-handoff-001.diff, CASSANDRA-2045-simplify-hinted-handoff-002.diff Currently when HH is enabled, hints are stored, and when a node comes back, we begin sending that node data. We do a lookup on the local node for the row to send. To help reduce read load (if a node is offline for long period of time) we should store the data we want forward the node locally instead. We wouldn't have to do any lookups, just take byte[] and send to the destination. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2500) Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter
[ https://issues.apache.org/jira/browse/CASSANDRA-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057811#comment-13057811 ] Jonathan Ellis commented on CASSANDRA-2500: --- No, it's available in the patch attached to this ticket. Ruby dbi client (for CQL) that conforms to AR:ConnectionAdapter --- Key: CASSANDRA-2500 URL: https://issues.apache.org/jira/browse/CASSANDRA-2500 Project: Cassandra Issue Type: Task Components: API Reporter: Jon Hermes Assignee: Pavel Yaskevich Labels: cql Fix For: 0.8.2 Attachments: 2500.txt, genthriftrb.txt, rbcql-0.0.0.tgz Create a ruby driver for CQL. Lacking something standard (such as py-dbapi), going with something common instead -- RoR ActiveRecord Connection Adapter (http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/AbstractAdapter.html). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057810#comment-13057810 ] Jonathan Ellis commented on CASSANDRA-2388: --- bq. another where data can be read in from anywhere This is totally antithetical to how hadoop is designed to work. I don't think it's worth supporting in-tree. ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica. - Key: CASSANDRA-2388 URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 Project: Cassandra Issue Type: Bug Components: Hadoop Affects Versions: 0.7.6, 0.8.0 Reporter: Eldon Stegall Assignee: Jeremy Hanna Labels: hadoop, inputformat Fix For: 0.7.7, 0.8.2 Attachments: 0002_On_TException_try_next_split.patch, CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch ColumnFamilyRecordReader only tries the first location for a given split. We should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2045) Simplify HH to decrease read load when nodes come back
[ https://issues.apache.org/jira/browse/CASSANDRA-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057812#comment-13057812 ] Jonathan Ellis commented on CASSANDRA-2045: --- It's fine the way it is. It's simpler if the deserializers can assume they will get a valid version. Simplify HH to decrease read load when nodes come back -- Key: CASSANDRA-2045 URL: https://issues.apache.org/jira/browse/CASSANDRA-2045 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Assignee: Nicholas Telford Fix For: 1.0 Attachments: 0001-Changed-storage-of-Hints-to-store-a-serialized-RowMu.patch, 0002-Refactored-HintedHandoffManager.sendRow-to-reduce-co.patch, 0003-Fixed-some-coding-style-issues.patch, 0004-Fixed-direct-usage-of-Gossiper.getEndpointStateForEn.patch, 0005-Removed-duplicate-failure-detection-conditionals.-It.patch, 0006-Removed-handling-of-old-style-hints.patch, 2045-v3.txt, CASSANDRA-2045-simplify-hinted-handoff-001.diff, CASSANDRA-2045-simplify-hinted-handoff-002.diff Currently when HH is enabled, hints are stored, and when a node comes back, we begin sending that node data. We do a lookup on the local node for the row to send. To help reduce read load (if a node is offline for long period of time) we should store the data we want forward the node locally instead. We wouldn't have to do any lookups, just take byte[] and send to the destination. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2786) After a minor compaction, deleted key-slices are visible again
[ https://issues.apache.org/jira/browse/CASSANDRA-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-2786: Attachment: 2786_part2.patch Yeah, turns out EchoedRow is also handling Row tombstones with no columns inside badly. Attaching patch with fix and unit test. 0.7 is not really impacted because it uses EchoedRow only for cleanup and don't use its isEmpty() function there (but I suppose we could make it throw an UnsupporteOperationException to be on the safe side). The patch actually ship with two changes that are not strictly related to the issue: # It fixes testEchoedRow in CompactionsTest. It wasn't using EchoedRow anymore (i.e, the test was useless). # It always forces deserialization for user submitted compaction (by opposition to only when the user submits only 1 sstable). It is done because exposing the forceDeserialization flag was necessary to write the test for this issue. Following that change, it was trivial to do the user submitted compaction change. It also fix a bad comment (forcing deserialization is only useful for forcing expired column to become tombstones, not for purging since purging will happen without force deserialization if it can). After a minor compaction, deleted key-slices are visible again -- Key: CASSANDRA-2786 URL: https://issues.apache.org/jira/browse/CASSANDRA-2786 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Environment: Reproduced on single Cassandra node (CentOS 5.5) Reproduced on single Cassandra node (Windows Server 2008) Reporter: rene kochen Assignee: Sylvain Lebresne Fix For: 0.8.1, 0.8.2 Attachments: 0001-Fix-wrong-purge-of-deleted-cf.patch, 2786_part2.patch, CassandraIssue.zip, CassandraIssueJava.zip After a minor compaction, deleted key-slices are visible again. Steps to reproduce: 1) Insert a row named test. 2) Insert 50 rows. During this step, row test is included in a major compaction: file-1, file-2, file-3 and file-4 compacted to file-5 (includes test). 3) Delete row named test. 4) Insert 50 rows. During this step, row test is included in a minor compaction: file-6, file-7, file-8 and file-9 compacted to file-10 (should include tombstoned test). After step 4, row test is live again. Test environment: Single node with empty database. Standard configured super-column-family (I see this behavior with several gc_grace settings (big and small values): create column family Customers with column_type = 'Super' and comparator = 'BytesType; In Cassandra 0.7.6 I observe the expected behavior, i.e. after step 4, the row is still deleted. I've included a .NET program to reproduce the problem. I will add a Java version later on. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2825) Auto bootstrapping the 4th node in a 4 node cluster doesn't work, when no token explicitly assigned in config.
[
https://issues.apache.org/jira/browse/CASSANDRA-2825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057960#comment-13057960
]
Brandon Williams commented on CASSANDRA-2825:
-
I'm unable to reproduce. What I don't understand is how token
61078635599166706937511052402724559481 can be involved if the first node
started at 0. My ring ends up looking like:
{noformat}
Address DC RackStatus State LoadOwns
Token
148820376661671484777635343879628161952
10.179.65.102 datacenter1 rack1 Up Normal 315.59 MB 12.53%
0
10.179.64.227 datacenter1 rack1 Up Normal 157.76 MB 49.97%
85015475407349018891169115382886066923
10.179.111.137 datacenter1 rack1 Up Normal 78.99 MB25.01%
127563185643974719468523634380546988377
10.179.110.154 datacenter1 rack1 Up Normal 39.55 MB12.49%
148820376661671484777635343879628161952
{noformat}
Auto bootstrapping the 4th node in a 4 node cluster doesn't work, when no
token explicitly assigned in config.
--
Key: CASSANDRA-2825
URL: https://issues.apache.org/jira/browse/CASSANDRA-2825
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.0, 0.8.1
Reporter: Michael Allen
Assignee: Brandon Williams
Fix For: 0.8.2
This was done in sequence. A, B, C, and D. Node A with token 0 explicitly
set in config. The rest with auto_bootstrap: true and no token explicitly
assigned. B and C work as expected. D ends up stealing C's token.
from system.log on C:
INFO [GossipStage:1] 2011-06-24 16:40:41,947 Gossiper.java (line 638) Node
/10.171.47.226 is now part of the cluster
INFO [GossipStage:1] 2011-06-24 16:40:41,947 Gossiper.java (line 606)
InetAddress /10.171.47.226 is now UP
INFO [GossipStage:1] 2011-06-24 16:42:09,432 StorageService.java (line 769)
Nodes /10.171.47.226 and /10.171.55.77 have the same token
61078635599166706937511052402724559481. /10.171.47.226 is the new owner
WARN [GossipStage:1] 2011-06-24 16:42:09,432 TokenMetadata.java (line 120)
Token 61078635599166706937511052402724559481 changing ownership from
/10.171.55.77 to /10.171.47.226
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
[ https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058044#comment-13058044 ] Patricio Echague commented on CASSANDRA-2034: - Depends on CASSANDRA-2045. Make Read Repair unnecessary when Hinted Handoff is enabled --- Key: CASSANDRA-2034 URL: https://issues.apache.org/jira/browse/CASSANDRA-2034 Project: Cassandra Issue Type: Improvement Components: Core Reporter: Jonathan Ellis Assignee: Patricio Echague Fix For: 1.0 Original Estimate: 8h Remaining Estimate: 8h Currently, HH is purely an optimization -- if a machine goes down, enabling HH means RR/AES will have less work to do, but you can't disable RR entirely in most situations since HH doesn't kick in until the FailureDetector does. Let's add a scheduled task to the mutate path, such that we return to the client normally after ConsistencyLevel is achieved, but after RpcTimeout we check the responseHandler write acks and write local hints for any missing targets. This would making disabling RR when HH is enabled a much more reasonable option, which has a huge impact on read throughput. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2768) AntiEntropyService excluding nodes that are on version 0.7 or sooner
[ https://issues.apache.org/jira/browse/CASSANDRA-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058061#comment-13058061 ] Héctor Izquierdo commented on CASSANDRA-2768: - I'm on 0.8.1 updating from 0.7.6-2 and I have stumbled upong this bug. I can't run repair on a node whose disk broke INFO [manual-repair-02182a20-5659-4aa0-aab9-2fff430f8a71] 2011-06-30 20:29:51,487 AntiEntropyService.java (line 179) Excluding /10.20.13.80 from repair because it is on version 0.7 or sooner. You should consider updating this node before running repair again. INFO [manual-repair-6b50f51a-f689-4825-bcb9-bebf68664117] 2011-06-30 20:29:51,487 AntiEntropyService.java (line 179) Excluding /10.20.13.76 from repair because it is on version 0.7 or sooner. You should consider updating this node before running repair again. INFO [manual-repair-6b50f51a-f689-4825-bcb9-bebf68664117] 2011-06-30 20:29:51,487 AntiEntropyService.java (line 179) Excluding /10.20.13.77 from repair because it is on version 0.7 or sooner. You should consider updating this node before running repair again. INFO [manual-repair-02182a20-5659-4aa0-aab9-2fff430f8a71] 2011-06-30 20:29:51,487 AntiEntropyService.java (line 179) Excluding /10.20.13.76 from repair because it is on version 0.7 or sooner. You should consider updating this node before running repair again. INFO [manual-repair-c46dd589-ed22-4b7a-809c-d97c094d2354] 2011-06-30 20:29:51,487 AntiEntropyService.java (line 179) Excluding /10.20.13.80 from repair because it is on version 0.7 or sooner. You should consider updating this node before running repair again. INFO [manual-repair-c46dd589-ed22-4b7a-809c-d97c094d2354] 2011-06-30 20:29:51,488 AntiEntropyService.java (line 179) Excluding /10.20.13.79 from repair because it is on version 0.7 or sooner. You should consider updating this node before running repair again. INFO [manual-repair-02182a20-5659-4aa0-aab9-2fff430f8a71] 2011-06-30 20:29:51,488 AntiEntropyService.java (line 782) No neighbors to repair with for sbs on (141784319550391026443072753096570088105,170141183460469231731687303715884105727]: manual-repair-02182a20-5659-4aa0-aab9-2fff430f8a71 completed. INFO [manual-repair-6b50f51a-f689-4825-bcb9-bebf68664117] 2011-06-30 20:29:51,487 AntiEntropyService.java (line 782) No neighbors to repair with for sbs on (170141183460469231731687303715884105727,28356863910078205288614550619314017621]: manual-repair-6b50f51a-f689-4825-bcb9-bebf68664117 completed. INFO [manual-repair-c46dd589-ed22-4b7a-809c-d97c094d2354] 2011-06-30 20:29:51,488 AntiEntropyService.java (line 782) No neighbors to repair with for sbs on (113427455640312821154458202477256070484,141784319550391026443072753096570088105]: manual-repair-c46dd589-ed22-4b7a-809c-d97c094d2354 completed. All nodes are on 0.8.1 AntiEntropyService excluding nodes that are on version 0.7 or sooner Key: CASSANDRA-2768 URL: https://issues.apache.org/jira/browse/CASSANDRA-2768 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.0 Environment: 4 node environment -- Originally 0.7.6-2 with a Keyspace defined with RF=3 Upgraded all nodes ( 1 at a time ) to version 0.8.0: For each node, the node was shut down, new version was turned on, using the existing data files / directories and a nodetool repair was run. Reporter: Sasha Dolgy When I run nodetool repair on any of the nodes, the /var/log/cassandra/system.log reports errors similar to: INFO [manual-repair-1c6b33bc-ef14-4ec8-94f6-f1464ec8bdec] 2011-06-13 21:28:39,877 AntiEntropyService.java (line 177) Excluding /10.128.34.18 from repair because it is on version 0.7 or sooner. You should consider updating this node before running repair again. ERROR [manual-repair-1c6b33bc-ef14-4ec8-94f6-f1464ec8bdec] 2011-06-13 21:28:39,877 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[manual-repair-1c6b33bc-ef14-4ec8-94f6-f1464ec8bdec,5,RMI Runtime] java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$KeyIterator.next(HashMap.java:828) at org.apache.cassandra.service.AntiEntropyService.getNeighbors(AntiEntropyService.java:173) at org.apache.cassandra.service.AntiEntropyService$RepairSession.run(AntiEntropyService.java:776) The INFO message and subsequent ERROR message are logged for 2 nodes .. I suspect that this is because RF=3. nodetool ring shows that all nodes are up. Client connections (read / write) are not having issues.. nodetool version on all nodes shows that each node is 0.8.0 At suggestion of some contributors, I have restarted each node and tried to run a nodetool repair
[jira] [Updated] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[
https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mck SembWever updated CASSANDRA-2388:
-
Attachment: CASSANDRA-2388-local-nodes-only.rough-sketch
Is CASSANDRA-2388-local-nodes-only-rough-sketch the direction we want then?
This is very initial code, i can't get {{new
JobClient(JobTracker.getAddress(conf),
conf).getClusterStatus().getActiveTrackerNames()}} to work, need a little help
here.
(Also CFRR.getLocations() can be drastically reduced).
ColumnFamilyRecordReader fails for a given split because a host is down, even
if records could reasonably be read from other replica.
-
Key: CASSANDRA-2388
URL: https://issues.apache.org/jira/browse/CASSANDRA-2388
Project: Cassandra
Issue Type: Bug
Components: Hadoop
Affects Versions: 0.7.6, 0.8.0
Reporter: Eldon Stegall
Assignee: Jeremy Hanna
Labels: hadoop, inputformat
Fix For: 0.7.7, 0.8.2
Attachments: 0002_On_TException_try_next_split.patch,
CASSANDRA-2388-addition1.patch, CASSANDRA-2388-local-nodes-only.rough-sketch,
CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch
ColumnFamilyRecordReader only tries the first location for a given split. We
should try multiple locations for a given split.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058101#comment-13058101 ] Melvin Wang commented on CASSANDRA-2819: a better way to go would be that we make the timeout part of Message obj so that when adding callback in MessagingService, we can pass in proper timeout to ExpiringMap and also in MessageDeliveryTask we can drop the message based on its own timeout. Not sure how complicated this is would be though. OutboundTcpConnection uses getRpcTimeout during connection which is a surprise to me. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-rw-timeouts.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058103#comment-13058103 ] Jonathan Ellis commented on CASSANDRA-2819: --- Why not just do a lookup base on verb type which is already part of Message? OTC should probably hardcode something reasonable, no reason for it to be related to RPC calls. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-rw-timeouts.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058113#comment-13058113 ] Melvin Wang commented on CASSANDRA-2819: yep, a simple look up will do. I guess I was confused by Request_Response messages. When we create request_response we don't record which type of message it replies to so in MessageDeliveryTask it's difficult to figure it out. Thus I wanted some way to associate the info to the request_response messages so that we could better time them out in MessageDeliveryTask. This is certainly complicated. Also in OutboundTcpConnection we better honor the per-verb timeout as well by providing a way to set the timeout value before we try to connect. If we want to hardcode, then it needs to be the max of (read, range read, write) since it lies on the path of these operations. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-rw-timeouts.patch Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2842) Hive JDBC connections fail with InvalidUrlException when both the C* and Hive JDBC drivers are loaded
Hive JDBC connections fail with InvalidUrlException when both the C* and Hive
JDBC drivers are loaded
-
Key: CASSANDRA-2842
URL: https://issues.apache.org/jira/browse/CASSANDRA-2842
Project: Cassandra
Issue Type: Bug
Reporter: Cathy Daw
Priority: Trivial
Hive connections fail with InvalidUrlException when both the C* and Hive JDBC
drivers are loaded, and it seems the URL is being interpreted as a C* url.
{code}
Caused an ERROR
[junit] Invalid connection url:jdbc:hive://127.0.0.1:1/default. should
start with jdbc:cassandra
[junit] org.apache.cassandra.cql.jdbc.InvalidUrlException: Invalid
connection url:jdbc:hive://127.0.0.1:1/default. should start with
jdbc:cassandra
[junit] at
org.apache.cassandra.cql.jdbc.CassandraDriver.connect(CassandraDriver.java:90)
[junit] at java.sql.DriverManager.getConnection(DriverManager.java:582)
[junit] at java.sql.DriverManager.getConnection(DriverManager.java:185)
[junit] at
com.datastax.bugRepros.repro_connection_error.test1_runHiveBeforeJdbc(repro_connection_error.java:34)
{code}
*Code Snippet: intended to illustrate the connection issues*
* Copy file to test directory
* Change package declaration
* run: ant test -Dtest.name=repro_conn_error
{code}
package com.datastax.bugRepros;
import java.sql.DriverManager;
import java.sql.Connection;
import java.sql.SQLException;
import java.util.Enumeration;
import org.junit.Test;
public class repro_conn_error
{
@Test
public void jdbcConnectionError() throws Exception
{
// Create Hive JDBC Connection - will succeed if
try
{
// Uncomment loading C* driver to reproduce bug
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
// Load Hive driver and connect
Class.forName(org.apache.hadoop.hive.jdbc.HiveDriver);
Connection hiveConn =
DriverManager.getConnection(jdbc:hive://127.0.0.1:1/default, , );
hiveConn.close();
System.out.println(successful hive connection);
} catch (SQLException e) {
System.out.println(unsuccessful hive connection);
e.printStackTrace();
}
// Create C* JDBC Connection
try
{
Class.forName(org.apache.cassandra.cql.jdbc.CassandraDriver);
Connection jdbcConn =
DriverManager.getConnection(jdbc:cassandra:root/root@127.0.0.1:9160/default);
jdbcConn.close();
System.out.println(successful c* connection);
} catch (SQLException e) {
System.out.println(unsuccessful c* connection);
e.printStackTrace();
}
// Print out all loaded JDBC drivers.
Enumeration d = java.sql.DriverManager.getDrivers();
while (d.hasMoreElements()) {
Object driverAsObject = d.nextElement();
System.out.println(JDBC driver= + driverAsObject);
}
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melvin Wang updated CASSANDRA-2819: --- Attachment: (was: rpc-rw-timeouts.patch) Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-timeouts-per-verb.diff Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melvin Wang updated CASSANDRA-2819: --- Attachment: rpc-timeouts-per-verb.diff Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-timeouts-per-verb.diff Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058144#comment-13058144 ] Melvin Wang commented on CASSANDRA-2819: scratch my comments about the OTC part. It is not true. What I want is a checkpoint after the server has processed the verb where we check if we are already timed out so that we won't bother to use the network bandwidth to send back the response. I will move this logic into MessagingService. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-timeouts-per-verb.diff Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058176#comment-13058176 ] Jonathan Ellis commented on CASSANDRA-2819: --- We check before processing to see if we can skip it entirely; probably not worth doing another check after processing too. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: rpc-timeouts-per-verb.diff Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-803) remove PropertyConfigurator from CassandraDaemon
[ https://issues.apache.org/jira/browse/CASSANDRA-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058209#comment-13058209 ] Marshall Pierce commented on CASSANDRA-803: --- It's a shame to add a hard dep on log4j for this, especially when both dynamically reloading configs and the thing that caused the use of PropertyConfigurator to get back in (CASSANDRA-1525, configuring via JMX) are already handled natively by Logback without any in-code configuration. (http://logback.qos.ch/manual/configuration.html#autoScan and http://logback.qos.ch/manual/jmxConfig.html). I'm happy to contribute a patch. What about simply making that static initializer block short-circuit if log4j isn't there? It's kind of hackish but it does the job. I'd be happy to rip out all the log4j specific stuff and replace it with slf4j if that patch would be used. remove PropertyConfigurator from CassandraDaemon Key: CASSANDRA-803 URL: https://issues.apache.org/jira/browse/CASSANDRA-803 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.6 Reporter: Jesse McConnell In order for users to make use of the EmbeddedCassandraService for unit testing they need to have a dependency declared on log4j. It would be nice if we could use the log4j-over-slf4j artifact to bridge this requirement for those of us using slf4j. http://www.slf4j.org/legacy.html#log4j-over-slf4j Currently it errors with the direct usage of the PropertyConfigurator in o.a.c.thrift.CassandraDaemon. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melvin Wang updated CASSANDRA-2819: --- Attachment: (was: rpc-timeouts-per-verb.diff) Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Melvin Wang updated CASSANDRA-2819: --- Attachment: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
[ https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058212#comment-13058212 ] Melvin Wang commented on CASSANDRA-2819: sure. However, the current logic in MessageDeliveryTask doesnt seem right. It compares against the creation time of MessageDeliveryTask itself. I added the creation time to Message class to address this. Split rpc timeout for read and write ops Key: CASSANDRA-2819 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819 Project: Cassandra Issue Type: New Feature Components: Core Reporter: Stu Hood Assignee: Melvin Wang Fix For: 1.0 Attachments: twttr-cassandra-0.8-counts-resync-rpc-rw-timeouts.diff Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
