[Cassandra Wiki] Trivial Update of MRYWalker by MRYWalker
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The MRYWalker page has been changed by MRYWalker: http://wiki.apache.org/cassandra/MRYWalker New page: Unfortunately this specific free funds are being given for the financial providers industry to receive them outside the mess they've got caused and are generally using it to take a position and the everyone else are unlikely to be able to get a loan at this sort of good price to take benefit from this, nevertheless there are some programs and we can at any rate benefit from realizing it in addition to knowing Susan Simpson is really a regular author on Obama-loanmodifications You've got a grab on this terrific fixer-upper on the outskirts of community last year, went in along the best of intentions You just need to have your personal debit minute card if you want to contain the loan dollars via that loan system [[http://www.paydayloans-melody.co.uk|same day payday loans online]] Quite a few payday loan companies are keen to say that a a bad credit score does not affect their own decision The purchases don't need to be that large essentially, just that they enable payment plans over a few weeks or months If you encountered various problems which compelled you to wait with generating the pay back of your loan on time, in that case you�ve come in the ideal place All it can is to hang the unavoidable and delay it for any later moment The applicant is provided an amount that ranges through �1000 to �25000 for 1-10 years which varies relating your needs
[Cassandra Wiki] Trivial Update of ElmerGood by ElmerGood
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ElmerGood page has been changed by ElmerGood: http://wiki.apache.org/cassandra/ElmerGood New page: My name is Elmer Good. I life in Tilshead (Great Britain).BR BR BR Feel free to surf to my web site; [[http://www.meguiars.co.nz/member/55156|click through the following web site]]
[jira] [Commented] (CASSANDRA-5442) Add support for specifying CAS commit CL
[ https://issues.apache.org/jira/browse/CASSANDRA-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627605#comment-13627605 ] Sylvain Lebresne commented on CASSANDRA-5442: - We should use a different WriteType value in the WriteTimeoutException returned, similarly to what we do for atomic batch writes (WriteType.BATCH_LOG means its the write to the batch log that has timeout, WriteType.BATCH means it's the write of the batch itself). For thrift, we don't have the WriteType value so far, and for atomic batches we've added a special case acknowledged_by_batchlog boolean, so I guess we can do the same in that case and add acknoweledged_by_paxos (or some other name) flag. Would probably have been easier to just expose the WriteType there too in the first place but well, we haven't. Add support for specifying CAS commit CL Key: CASSANDRA-5442 URL: https://issues.apache.org/jira/browse/CASSANDRA-5442 Project: Cassandra Issue Type: Sub-task Components: API, Core Reporter: Jonathan Ellis Fix For: 2.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-3668) Parallel streaming for sstableloader
[ https://issues.apache.org/jira/browse/CASSANDRA-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627604#comment-13627604 ] Viktor Jevdokimov commented on CASSANDRA-3668: -- Any progress on the issue? Parallel streaming for sstableloader Key: CASSANDRA-3668 URL: https://issues.apache.org/jira/browse/CASSANDRA-3668 Project: Cassandra Issue Type: Improvement Components: API Reporter: Manish Zope Assignee: Yuki Morishita Priority: Minor Labels: streaming Fix For: 2.0 Attachments: 3668-1.1.txt, 3668-1.1-v2.txt, 3688-reply_before_closing_writer.txt, sstable-loader performance.txt Original Estimate: 48h Remaining Estimate: 48h One of my colleague had reported the bug regarding the degraded performance of the sstable generator and sstable loader. ISSUE :- https://issues.apache.org/jira/browse/CASSANDRA-3589 As stated in above issue generator performance is rectified but performance of the sstableloader is still an issue. 3589 is marked as duplicate of 3618.Both issues shows resolved status.But the problem with sstableloader still exists. So opening other issue so that sstbleloader problem should not go unnoticed. FYI : We have tested the generator part with the patch given in 3589.Its Working fine. Please let us know if you guys require further inputs from our 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
[Cassandra Wiki] Update of AdminGroup by GavinMcDonald
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The AdminGroup page has been changed by GavinMcDonald: http://wiki.apache.org/cassandra/AdminGroup?action=diffrev1=2rev2=4 Comment: create an AdminGroup with intial members as supplied by INFRA-5968 - #acl AdminGroup:read,write,delete,revert,admin -All:read + #acl AdminGroup:read,write,admin,revert,delete -All:read - This is a list of people who can do editing of the LocalBadContent page and add other folks to this page and ContributorsGroup : + This is a list of people who can do editing of the LocalBadContent and ContributorsGroup pages: * GavinMcDonald - * DanielShahaf + * DaveBrosius * JonathanEllis - * JeremyHanna
[Cassandra Wiki] Update of ContributorsGroup by GavinMcDonald
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ContributorsGroup page has been changed by GavinMcDonald: http://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=1rev2=3 Comment: Create an initial ContributorsGroup. Do not remove the AdminGroup entry. #acl AdminGroup:read,write,admin,revert,delete All:read - '''Contributors''' with permission to edit the Subversion wiki – read, write, delete and revert pages or individual changes. To be added to this group, please send a brief request to the dev.at.subversion-dot-apache-dot-org mailing list including your wiki username. No mailing list subscription required. + '''Contributors''' with permission to edit the Cassandra wiki – read, write, delete and revert pages or individual changes. To be added to this group, please send a brief request to the dev.at.cassandra.apache-dot-org mailing list including your wiki username. No mailing list subscription required. - Related: [[AdminGroup| Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves. + Related: [[AdminGroup| Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves. NOTE: This list is not publicly viewable. * AdminGroup - * JohnatanEllis
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627707#comment-13627707 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. this sounds exactly like what we discussed to preserve correctness Not exactly. What we need to preserve correctness is make sure we don't start a new round (i.e. we don't propose our own value) until we can guarantee that a quorum of replica have learned about the last MRC. And that is correctly done by this patch, I'm not contesting that. However, the patch equates not starting a new round with throwing an UAE, which is what I have a problem with. Let me put it another way: the reason why I suggested storing the mostRecentUpdate is so that if we get in a state where less than a quorum of replica have learned the last commit due to some errors, then we can repair them by sending them that mostRecentUpdate (after which we'd be able to make progress again). But that's not what the current patch does. The only time the current patch uses the mostRecentUpdate is when we have already validated that we have a quorum of node on the MRC. In other words, it uses the mostRecentUpdate only as a slight optimisation but not to avoid the algorithm getting stuck, which should be the main goal (the only goal really imo). Anyway, probably I haven't been clear on what the alternative I'm suggesting is, so to clear that up I've pushed the patch at https://github.com/pcmanus/cassandra/commits/5062-5 (on top of the last v4). There is 4 commits in fact, but the important one is the first one only. As you'll see, this still respect the invariant that we don't start a new round until we can guarantee that a quorum of replica have learned about the last MRC, but if we can't prove that we have such a quorum, we repair nodes and move on with the algorithm instead of throwing an exception. The 2nd commit is just doing the let's skip waiting on response once we got a 'not promised', since that's trivial on top of the preceding patch. As for the two last one, I wanted to check my use the Commit class more generally idea. After having done it, I do think it make the clone slightly more readable, if only because it allows to encapsulate better a few behavior in the Commit class, because it avoid duplicating serialization code too much, and because it removes PrepareRequest and ProposeRequest that are kind of uninteresting (and I don't find that grouping things even for prepare is really making things worth). But I'll agree to disagree if you still think it's a bad idea. bq. Hmm, not sure where to fit this in. Imo, the best option would be to have a 'paxos ttl' setting in the user CFs like we have gc_grace. Then each write to the PaxosCF would use the value for the CF this is an update of (i.e. not all row in PaxosCF would have the same ttl if you don't same the same ttl in all of your CF, but that's ok). One small concern might be that currently we share the same Paxos state for rows belonging to different CF is they share the same key. But maybe that just mean that we should stop doing that and include the cfId in the paxos sate row key. After all, the API doesn't allow to do a CAS that span multiple CF anyway. And I'm not convinced twisting the API to allow it is worth the trouble. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627717#comment-13627717 ] Sylvain Lebresne commented on CASSANDRA-5062: - Nit: Just learned about http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/util/concurrent/Striped.html. Could replace our array of locks. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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
[Cassandra Wiki] Update of ContributorsGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ContributorsGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=3rev2=4 Related: [[AdminGroup| Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves. NOTE: This list is not publicly viewable. * AdminGroup + * ChrisBroome + * MarkWatson
[Cassandra Wiki] Update of AdminGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The AdminGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/AdminGroup?action=diffrev1=4rev2=5 * GavinMcDonald * DaveBrosius * JonathanEllis + * BrandonWilliams
[Cassandra Wiki] Update of AdminGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The AdminGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/AdminGroup?action=diffrev1=5rev2=6 * DaveBrosius * JonathanEllis * BrandonWilliams + * jeremyhanna
[Cassandra Wiki] Update of ContributorsGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ContributorsGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=4rev2=5 Related: [[AdminGroup| Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves. NOTE: This list is not publicly viewable. * AdminGroup + * Alexis Wilke * ChrisBroome + * EricEvans + * ErnieHershey + * JoaquinCasares + * LukasGutschmidt + * MakiWatanabe * MarkWatson + * MatthewDennis + * StephenConnolly + * thepaul
[jira] [Commented] (CASSANDRA-5418) repair freezing
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627729#comment-13627729
]
Igor Ivanov commented on CASSANDRA-5418:
Actually, it helped only temporarily, and appendFromStream now asserts when I
try to bootstrap new node.
repair freezing
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2, 1.2.3
Environment: 5 nodes, RackInferring snitch, OpenVZ VMs, Centos 6,
Oracle JVM with JNA enabled.
Reporter: Igor Ivanov
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
{quote}
Then I see frozen
[jira] [Commented] (CASSANDRA-5418) streaming fails
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627733#comment-13627733
]
Igor Ivanov commented on CASSANDRA-5418:
We are not using internode encryption, but compression is used.
streaming fails
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2, 1.2.3
Environment: 5 nodes, vnodes enabled, encryption disabled,
compression enabled, RackInferring snitch, Centos 6, Oracle JVM with JNA
enabled.
Reporter: Igor Ivanov
Priority: Critical
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3
[jira] [Updated] (CASSANDRA-5418) streaming fails
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Ivanov updated CASSANDRA-5418:
---
Priority: Critical (was: Major)
Environment: 5 nodes, vnodes enabled, encryption disabled, compression
enabled, RackInferring snitch, Centos 6, Oracle JVM with JNA enabled. (was: 5
nodes, RackInferring snitch, OpenVZ VMs, Centos 6, Oracle JVM with JNA enabled.)
Summary: streaming fails (was: repair freezing)
streaming fails
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2, 1.2.3
Environment: 5 nodes, vnodes enabled, encryption disabled,
compression enabled, RackInferring snitch, Centos 6, Oracle JVM with JNA
enabled.
Reporter: Igor Ivanov
Priority: Critical
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
[jira] [Created] (CASSANDRA-5450) cluster
nivance created CASSANDRA-5450: -- Summary: cluster Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.194 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.193 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- 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-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nivance updated CASSANDRA-5450: --- Summary: cluster : Host ID collision (was: cluster) cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- 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-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nivance updated CASSANDRA-5450: --- Description: I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.194 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.193 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? was: I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.194 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.193 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at
[jira] [Commented] (CASSANDRA-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627772#comment-13627772 ] Brandon Williams commented on CASSANDRA-5450: - bq. Is it a bug or is my Configuration wrong? Are these virtual machines you cloned or in any way copied the system tables between? cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- 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
[Cassandra Wiki] Update of AdminGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The AdminGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/AdminGroup?action=diffrev1=6rev2=7 * DaveBrosius * JonathanEllis * BrandonWilliams - * jeremyhanna
[Cassandra Wiki] Update of FrontPage by DaveBrosius
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Cassandra Wiki for
change notification.
The FrontPage page has been changed by DaveBrosius:
http://wiki.apache.org/cassandra/FrontPage?action=diffrev1=96rev2=97
= Cassandra Wiki =
+
+ {{{#!wiki red/solid
+ If you would like to contribute to this wiki, please send an email to the
mailing list dev.at.cassandra.apache-dot-org and we will be happy to add you.
Contributions welcome!
+ }}}
Cassandra is a highly scalable, eventually consistent, distributed,
structured key-value store. Cassandra brings together the distributed systems
technologies from
[[http://web.archive.org/web/20120221222718/http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf|Dynamo]]
and the data model from Google's
[[http://research.google.com/archive/bigtable-osdi06.pdf|BigTable]]. Like
Dynamo, Cassandra is
[[http://www.allthingsdistributed.com/2008/12/eventually_consistent.html|eventually
consistent]]. Like BigTable, Cassandra provides a ColumnFamily-based data
model richer than typical key/value systems.
[Cassandra Wiki] Update of ContributorsGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ContributorsGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=5rev2=6 Related: [[AdminGroup| Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves. NOTE: This list is not publicly viewable. * AdminGroup + * AaronMorton * Alexis Wilke * ChrisBroome * EricEvans * ErnieHershey * JoaquinCasares * LukasGutschmidt + * LukasWingerberg * MakiWatanabe * MarkWatson * MatthewDennis * StephenConnolly - * thepaul + * SylvainLebresne + * TylerHobbs + * yukim
[Cassandra Wiki] Update of AdminGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The AdminGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/AdminGroup?action=diffrev1=7rev2=8 * DaveBrosius * JonathanEllis * BrandonWilliams + * jeremyhanna
[Cassandra Wiki] Update of ContributorsGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ContributorsGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=6rev2=7 * MatthewDennis * StephenConnolly * SylvainLebresne + * thepaul * TylerHobbs * yukim
[Cassandra Wiki] Update of ContributorsGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ContributorsGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=7rev2=8 * ChrisBroome * EricEvans * ErnieHershey + * gdusbabek + * JasonBrown * JoaquinCasares * LukasGutschmidt * LukasWingerberg * MakiWatanabe * MarkWatson * MatthewDennis + * SergeRider * StephenConnolly * SylvainLebresne * thepaul * TylerHobbs + * Victor Lownes * yukim + * zznate
git commit: remove vestigal Table.indexLocks
Updated Branches:
refs/heads/trunk 3852085a6 - b31f48d30
remove vestigal Table.indexLocks
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/b31f48d3
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/b31f48d3
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/b31f48d3
Branch: refs/heads/trunk
Commit: b31f48d30e1b667c657bd0d5faf907a171073231
Parents: 3852085
Author: Jonathan Ellis jbel...@apache.org
Authored: Wed Apr 10 09:53:22 2013 -0500
Committer: Jonathan Ellis jbel...@apache.org
Committed: Wed Apr 10 09:53:22 2013 -0500
--
src/java/org/apache/cassandra/db/Table.java | 33 ++---
1 files changed, 10 insertions(+), 23 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/b31f48d3/src/java/org/apache/cassandra/db/Table.java
--
diff --git a/src/java/org/apache/cassandra/db/Table.java
b/src/java/org/apache/cassandra/db/Table.java
index 551b20a..f158e4c 100644
--- a/src/java/org/apache/cassandra/db/Table.java
+++ b/src/java/org/apache/cassandra/db/Table.java
@@ -19,7 +19,6 @@ package org.apache.cassandra.db;
import java.io.File;
import java.io.IOException;
-import java.nio.ByteBuffer;
import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
@@ -31,7 +30,10 @@ import com.google.common.collect.Iterables;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
-import org.apache.cassandra.config.*;
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.config.DatabaseDescriptor;
+import org.apache.cassandra.config.KSMetaData;
+import org.apache.cassandra.config.Schema;
import org.apache.cassandra.db.commitlog.CommitLog;
import org.apache.cassandra.db.filter.ColumnSlice;
import org.apache.cassandra.db.filter.QueryFilter;
@@ -71,7 +73,6 @@ public class Table
/* ColumnFamilyStore per column family */
private final ConcurrentMapUUID, ColumnFamilyStore columnFamilyStores =
new ConcurrentHashMapUUID, ColumnFamilyStore();
-private final Object[] indexLocks;
private volatile AbstractReplicationStrategy replicationStrategy;
public static final FunctionString,Table tableTransformer = new
FunctionString, Table()
{
@@ -260,10 +261,6 @@ public class Table
assert metadata != null : Unknown keyspace + table;
createReplicationStrategy(metadata);
-indexLocks = new Object[DatabaseDescriptor.getConcurrentWriters() *
128];
-for (int i = 0; i indexLocks.length; i++)
-indexLocks[i] = new Object();
-
for (CFMetaData cfm : new
ArrayListCFMetaData(metadata.cfMetaData().values()))
{
logger.debug(Initializing {}.{}, getName(), cfm.cfName);
@@ -403,22 +400,17 @@ public class Table
switchLock.readLock().lock();
try
{
-// Our index lock is per-row, but we don't want to hold writes for
too long, so for large rows
-// we release the lock between pages
SliceQueryPager pager = new SliceQueryPager(cfs, key,
ColumnSlice.ALL_COLUMNS_ARRAY);
while (pager.hasNext())
{
-synchronized (cfs.table.indexLockFor(key.key))
+ColumnFamily cf = pager.next();
+ColumnFamily cf2 = cf.cloneMeShallow();
+for (Column column : cf)
{
-ColumnFamily cf = pager.next();
-ColumnFamily cf2 = cf.cloneMeShallow();
-for (Column column : cf)
-{
-if (cfs.indexManager.indexes(column.name(), indexes))
-cf2.addColumn(column);
-}
-cfs.indexManager.indexRow(key.key, cf2);
+if (cfs.indexManager.indexes(column.name(), indexes))
+cf2.addColumn(column);
}
+cfs.indexManager.indexRow(key.key, cf2);
}
}
finally
@@ -427,11 +419,6 @@ public class Table
}
}
-private Object indexLockFor(ByteBuffer key)
-{
-return indexLocks[Math.abs(key.hashCode() % indexLocks.length)];
-}
-
public ListFuture? flush()
{
ListFuture? futures = new ArrayListFuture?();
[jira] [Commented] (CASSANDRA-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627879#comment-13627879 ] Jonathan Ellis commented on CASSANDRA-5062: --- If we're not going to wait for everyone we sent a message to, should we allow propose/commit to accept ballots newer than the one it has promised, on the theory that our proposer won't do anything nefarious, so a newer ballot must mean that we raced with a pending prepare? Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5062) Support CAS
[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627880#comment-13627880
]
Jonathan Ellis commented on CASSANDRA-5062:
---
(Re Striped, in this simple case I'd rather have the syntactic sugar of
{{synchronized}} and roll my own lock array. Why didn't java7 make locks
auto-closeable?)
Support CAS
---
Key: CASSANDRA-5062
URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
Project: Cassandra
Issue Type: New Feature
Components: API, Core
Reporter: Jonathan Ellis
Fix For: 2.0
Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg,
half-baked commit 3.jpg
Strong consistency is not enough to prevent race conditions. The classic
example is user account creation: we want to ensure usernames are unique, so
we only want to signal account creation success if nobody else has created
the account yet. But naive read-then-write allows clients to race and both
think they have a green light to create.
--
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-5418) streaming fails
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627903#comment-13627903
]
Yuki Morishita commented on CASSANDRA-5418:
---
Igor, can you provide more info about this?
Do you see the same AssertionError for every CFs or the specific one? If the
latter, can you post the definition of that CF?
streaming fails
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2, 1.2.3
Environment: 5 nodes, vnodes enabled, encryption disabled,
compression enabled, RackInferring snitch, Centos 6, Oracle JVM with JNA
enabled.
Reporter: Igor Ivanov
Priority: Critical
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
[jira] [Commented] (CASSANDRA-5448) counters upgrade test fails
[
https://issues.apache.org/jira/browse/CASSANDRA-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627924#comment-13627924
]
Sylvain Lebresne commented on CASSANDRA-5448:
-
I think the test is to blame. It uses 2 nodes with RF=2, but uses CL.ONE to do
his inserts and checks, which looks wrong. I pushed a fix to that test to use
QUORUM instead. With that, I was able to get the test go past line 108 ...
until line 109. But then it broke because I was using the current 1.2 branch
and CASSANDRA-5187 has broken ccm, so I'll need to fix ccm. I'll test on some
older C* version but the test is so damn long that fell free to test it on your
side.
counters upgrade test fails
---
Key: CASSANDRA-5448
URL: https://issues.apache.org/jira/browse/CASSANDRA-5448
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Brandon Williams
Assignee: Sylvain Lebresne
{noformat}
Test for bug of #4436 ... FAIL
==
FAIL: Test for bug of #4436
--
Traceback (most recent call last):
File /srv/cassandra-dtest/counter_tests.py, line 108, in upgrade_test
check(1)
File /srv/cassandra-dtest/counter_tests.py, line 96, in check
assert row[1] == i * updates, Unexpected value %s % str(row)
AssertionError: Unexpected value [23, 5011]
--
{noformat}
I tested as far back as 1.2.0, so this is pretty old.
--
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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627966#comment-13627966 ] Jonathan Ellis commented on CASSANDRA-5062: --- I was going to write that I'm still not a fan of everything is a Commit approach, because the duplicated information in PaxosState and PrepareResponse matches the semantics of what we are doing poorly -- it appears to imply that different responses could be for different keys, or even have different keys for the two Commits in PaxosState (or PrepareResponse). It also obfuscates that prepare only cares about ballot. But then I started adding cfid and we have the same problem at the ColumnFamily level. So screw it, I welcome my new Commit overlord. But I'm adding some asserts to make myself feel better. Pushed cfid incorporation and TTL code to https://github.com/pcmanus/cassandra/commits/5062-5. (I think to start with using gcgs for TTL is fine.) Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627973#comment-13627973 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. should we allow propose/commit to accept ballots newer than the one it has promised That comment made me realize that at least for the commit part, my patch was assuming that we were pretty much always accepting commits, so it was slightly broken. So I've pushed one more commit on the branch to fix that. Hopefully that makes sense. I note that I just saw your last push and that last commit is not on top of that but rather on top of my earlier v5. Maybe you can just cherry-pick that last commit? For the propose, I think accepting newer-than-promised ballot would be ok, yes. The promise made during prepare is to not accept anything older than the ballot we promise to, but accepting something newer should be fine. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627977#comment-13627977 ] Sylvain Lebresne commented on CASSANDRA-5062: - bq. I think to start with using gcgs for TTL is fine I though of that, but I'm slightly afraid of people using gcgs == 0 on a CF because they are not doing any deletes on that CF (but may have a fixed TTL on everything, which is a valid reason to use gcgs == 0). I'd be fine spawning a following ticket to create a separate setting however. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5424) nodetool repair -pr on all nodes won't repair the full range when a Keyspace isn't in all DC's
[
https://issues.apache.org/jira/browse/CASSANDRA-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-5424:
--
Attachment: 5424-1.1.txt
Patch attached against 1.1.
It is basically rewrite of AntiEntropyService.getNeighbors, but I moved that
static method to StorageService and renamed as getReplicaNodes because I felt
that is more suitable place. And the method returns addresses of the replica
nodes for given KS and range. Previously the method does not return the address
of the local node, but the new version does only when the local node holds the
replica.
So for the above case, /10.72.111.225 sends tree request only to other nodes in
Analytics DC for the range it holds, and if there is difference, the node let
others to repair the data each other.
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
--
Key: CASSANDRA-5424
URL: https://issues.apache.org/jira/browse/CASSANDRA-5424
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Jeremiah Jordan
Priority: Critical
Attachments: 5424-1.1.txt
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
Commands follow, but the TL;DR of it, range
(127605887595351923798765477786913079296,0] doesn't get repaired between .38
node and .236 node until I run a repair, no -pr, on .38
It seems like primary arnge calculation doesn't take schema into account, but
deciding who to ask for merkle tree's from does.
{noformat}
Address DC RackStatus State LoadOwns
Token
127605887595351923798765477786913079296
10.72.111.225 Cassandra rack1 Up Normal 455.87 KB 25.00%
0
10.2.29.38 Analytics rack1 Up Normal 40.74 MB25.00%
42535295865117307932921825928971026432
10.46.113.236 Analytics rack1 Up Normal 20.65 MB50.00%
127605887595351923798765477786913079296
create keyspace Keyspace1
with placement_strategy = 'NetworkTopologyStrategy'
and strategy_options = {Analytics : 2}
and durable_writes = true;
---
# nodetool -h 10.2.29.38 repair -pr Keyspace1 Standard1
[2013-04-03 15:46:58,000] Starting repair command #1, repairing 1 ranges for
keyspace Keyspace1
[2013-04-03 15:47:00,881] Repair session b79b4850-9c75-11e2--8b5bf6ebea9e
for range (0,42535295865117307932921825928971026432] finished
[2013-04-03 15:47:00,881] Repair command #1 finished
root@ip-10-2-29-38:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,009 AntiEntropyService.java
(line 676) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] new session: will
sync a1/10.2.29.38, /10.46.113.236 on range
(0,42535295865117307932921825928971026432] for Keyspace1.[Standard1]
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,015 AntiEntropyService.java
(line 881) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] requesting merkle
trees for Standard1 (to [/10.46.113.236, a1/10.2.29.38])
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,202 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from /10.46.113.236
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,697 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from a1/10.2.29.38
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,879 AntiEntropyService.java
(line 1015) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Endpoints
/10.46.113.236 and a1/10.2.29.38 are consistent for Standard1
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 788) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Standard1 is fully
synced
INFO [AntiEntropySessions:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 722) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] session completed
successfully
root@ip-10-46-113-236:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropyStage:1] 2013-04-03 15:46:59,944 AntiEntropyService.java
(line 244) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Sending completed
merkle tree to /10.2.29.38 for (Keyspace1,Standard1)
root@ip-10-72-111-225:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
[jira] [Updated] (CASSANDRA-5424) nodetool repair -pr on all nodes won't repair the full range when a Keyspace isn't in all DC's
[
https://issues.apache.org/jira/browse/CASSANDRA-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-5424:
--
Assignee: Yuki Morishita
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
--
Key: CASSANDRA-5424
URL: https://issues.apache.org/jira/browse/CASSANDRA-5424
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Jeremiah Jordan
Assignee: Yuki Morishita
Priority: Critical
Fix For: 1.1.11
Attachments: 5424-1.1.txt
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
Commands follow, but the TL;DR of it, range
(127605887595351923798765477786913079296,0] doesn't get repaired between .38
node and .236 node until I run a repair, no -pr, on .38
It seems like primary arnge calculation doesn't take schema into account, but
deciding who to ask for merkle tree's from does.
{noformat}
Address DC RackStatus State LoadOwns
Token
127605887595351923798765477786913079296
10.72.111.225 Cassandra rack1 Up Normal 455.87 KB 25.00%
0
10.2.29.38 Analytics rack1 Up Normal 40.74 MB25.00%
42535295865117307932921825928971026432
10.46.113.236 Analytics rack1 Up Normal 20.65 MB50.00%
127605887595351923798765477786913079296
create keyspace Keyspace1
with placement_strategy = 'NetworkTopologyStrategy'
and strategy_options = {Analytics : 2}
and durable_writes = true;
---
# nodetool -h 10.2.29.38 repair -pr Keyspace1 Standard1
[2013-04-03 15:46:58,000] Starting repair command #1, repairing 1 ranges for
keyspace Keyspace1
[2013-04-03 15:47:00,881] Repair session b79b4850-9c75-11e2--8b5bf6ebea9e
for range (0,42535295865117307932921825928971026432] finished
[2013-04-03 15:47:00,881] Repair command #1 finished
root@ip-10-2-29-38:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,009 AntiEntropyService.java
(line 676) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] new session: will
sync a1/10.2.29.38, /10.46.113.236 on range
(0,42535295865117307932921825928971026432] for Keyspace1.[Standard1]
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,015 AntiEntropyService.java
(line 881) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] requesting merkle
trees for Standard1 (to [/10.46.113.236, a1/10.2.29.38])
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,202 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from /10.46.113.236
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,697 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from a1/10.2.29.38
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,879 AntiEntropyService.java
(line 1015) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Endpoints
/10.46.113.236 and a1/10.2.29.38 are consistent for Standard1
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 788) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Standard1 is fully
synced
INFO [AntiEntropySessions:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 722) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] session completed
successfully
root@ip-10-46-113-236:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropyStage:1] 2013-04-03 15:46:59,944 AntiEntropyService.java
(line 244) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Sending completed
merkle tree to /10.2.29.38 for (Keyspace1,Standard1)
root@ip-10-72-111-225:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
root@ip-10-72-111-225:/home/ubuntu#
---
# nodetool -h 10.46.113.236 repair -pr Keyspace1 Standard1
[2013-04-03 15:48:00,274] Starting repair command #1, repairing 1 ranges for
keyspace Keyspace1
[2013-04-03 15:48:02,032] Repair session dcb91540-9c75-11e2--a839ee2ccbef
for range
(42535295865117307932921825928971026432,127605887595351923798765477786913079296]
finished
[2013-04-03 15:48:02,033] Repair command #1 finished
root@ip-10-46-113-236:/home/ubuntu# grep dcb91540-9c75-11e2--a839ee2ccbef
/var/log/cassandra/system.log
INFO [AntiEntropySessions:5]
git commit: Fix TimeoutException when there is a firewall issue. patch by Vijay; reviewed by jbellis for CASSANDRA-3533
Updated Branches:
refs/heads/trunk b31f48d30 - 576efcd81
Fix TimeoutException when there is a firewall issue.
patch by Vijay; reviewed by jbellis for CASSANDRA-3533
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/576efcd8
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/576efcd8
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/576efcd8
Branch: refs/heads/trunk
Commit: 576efcd8121e70e7d550fdce9432be43690a4b1d
Parents: b31f48d
Author: Vijay Parthasarathy vijay2...@gmail.com
Authored: Wed Apr 10 10:21:51 2013 -0700
Committer: Vijay Parthasarathy vijay2...@gmail.com
Committed: Wed Apr 10 10:21:51 2013 -0700
--
src/java/org/apache/cassandra/gms/EchoMessage.java | 29 ++
src/java/org/apache/cassandra/gms/Gossiper.java| 44 ++-
.../org/apache/cassandra/net/MessagingService.java |4 +
.../apache/cassandra/service/EchoVerbHandler.java | 21 +++
.../apache/cassandra/service/StorageService.java |1 +
.../apache/cassandra/io/CompactSerializerTest.java |1 +
6 files changed, 86 insertions(+), 14 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/576efcd8/src/java/org/apache/cassandra/gms/EchoMessage.java
--
diff --git a/src/java/org/apache/cassandra/gms/EchoMessage.java
b/src/java/org/apache/cassandra/gms/EchoMessage.java
new file mode 100644
index 000..3f5f566
--- /dev/null
+++ b/src/java/org/apache/cassandra/gms/EchoMessage.java
@@ -0,0 +1,29 @@
+package org.apache.cassandra.gms;
+
+import java.io.DataInput;
+import java.io.DataOutput;
+import java.io.IOException;
+
+import org.apache.cassandra.io.IVersionedSerializer;
+
+public class EchoMessage
+{
+public static IVersionedSerializerEchoMessage serializer = new
EchoMessageSerializer();
+
+public static class EchoMessageSerializer implements
IVersionedSerializerEchoMessage
+{
+public void serialize(EchoMessage t, DataOutput out, int version)
throws IOException
+{
+}
+
+public EchoMessage deserialize(DataInput in, int version) throws
IOException
+{
+return new EchoMessage();
+}
+
+public long serializedSize(EchoMessage t, int version)
+{
+return 0;
+}
+}
+}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/576efcd8/src/java/org/apache/cassandra/gms/Gossiper.java
--
diff --git a/src/java/org/apache/cassandra/gms/Gossiper.java
b/src/java/org/apache/cassandra/gms/Gossiper.java
index ae920e1..04ece7a 100644
--- a/src/java/org/apache/cassandra/gms/Gossiper.java
+++ b/src/java/org/apache/cassandra/gms/Gossiper.java
@@ -33,6 +33,8 @@ import org.slf4j.LoggerFactory;
import org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor;
import org.apache.cassandra.config.DatabaseDescriptor;
import org.apache.cassandra.dht.Token;
+import org.apache.cassandra.net.IAsyncCallback;
+import org.apache.cassandra.net.MessageIn;
import org.apache.cassandra.net.MessageOut;
import org.apache.cassandra.net.MessagingService;
import org.apache.cassandra.service.StorageService;
@@ -759,21 +761,35 @@ public class Gossiper implements
IFailureDetectionEventListener, GossiperMBean
}
-private void markAlive(InetAddress addr, EndpointState localState)
+private void markAlive(final InetAddress addr, final EndpointState
localState)
{
-if (logger.isTraceEnabled())
-logger.trace(marking as alive {}, addr);
-localState.markAlive();
-localState.updateTimestamp(); // prevents doStatusCheck from racing us
and evicting if it was down aVeryLongTime
-liveEndpoints.add(addr);
-unreachableEndpoints.remove(addr);
-expireTimeEndpointMap.remove(addr);
-logger.debug(removing expire time for endpoint : + addr);
-logger.info(InetAddress {} is now UP, addr);
-for (IEndpointStateChangeSubscriber subscriber : subscribers)
-subscriber.onAlive(addr, localState);
-if (logger.isTraceEnabled())
-logger.trace(Notified + subscribers);
+MessageOutEchoMessage echoMessage = new
MessageOutEchoMessage(MessagingService.Verb.ECHO, new EchoMessage(),
EchoMessage.serializer);
+logger.trace(Sending a EchoMessage to {}, addr);
+IAsyncCallback echoHandler = new IAsyncCallback()
+{
+public boolean isLatencyForSnitch()
+{
+return false;
+}
+
+public void response(MessageIn msg)
+{
+if (logger.isTraceEnabled())
+logger.trace(marking as alive {}, addr);
+
[jira] [Created] (CASSANDRA-5451) Add Paxos TTL setting
Jonathan Ellis created CASSANDRA-5451: - Summary: Add Paxos TTL setting Key: CASSANDRA-5451 URL: https://issues.apache.org/jira/browse/CASSANDRA-5451 Project: Cassandra Issue Type: Sub-task Reporter: Jonathan Ellis Priority: Minor -- 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-5062) Support CAS
[ https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628028#comment-13628028 ] Jonathan Ellis commented on CASSANDRA-5062: --- Cherry-picked, and made eraseInProgressProposal actually generate different cql. :) Also I forgot to use -p so the proposal accept change is in the same commit. Created CASSANDRA-5451 for TTL config. Support CAS --- Key: CASSANDRA-5062 URL: https://issues.apache.org/jira/browse/CASSANDRA-5062 Project: Cassandra Issue Type: New Feature Components: API, Core Reporter: Jonathan Ellis Fix For: 2.0 Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg, half-baked commit 3.jpg Strong consistency is not enough to prevent race conditions. The classic example is user account creation: we want to ensure usernames are unique, so we only want to signal account creation success if nobody else has created the account yet. But naive read-then-write allows clients to race and both think they have a green light to create. -- 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-5424) nodetool repair -pr on all nodes won't repair the full range when a Keyspace isn't in all DC's
[
https://issues.apache.org/jira/browse/CASSANDRA-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-5424:
--
Attachment: 5424-1.1.txt
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
--
Key: CASSANDRA-5424
URL: https://issues.apache.org/jira/browse/CASSANDRA-5424
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Jeremiah Jordan
Assignee: Yuki Morishita
Priority: Critical
Fix For: 1.1.11
Attachments: 5424-1.1.txt
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
Commands follow, but the TL;DR of it, range
(127605887595351923798765477786913079296,0] doesn't get repaired between .38
node and .236 node until I run a repair, no -pr, on .38
It seems like primary arnge calculation doesn't take schema into account, but
deciding who to ask for merkle tree's from does.
{noformat}
Address DC RackStatus State LoadOwns
Token
127605887595351923798765477786913079296
10.72.111.225 Cassandra rack1 Up Normal 455.87 KB 25.00%
0
10.2.29.38 Analytics rack1 Up Normal 40.74 MB25.00%
42535295865117307932921825928971026432
10.46.113.236 Analytics rack1 Up Normal 20.65 MB50.00%
127605887595351923798765477786913079296
create keyspace Keyspace1
with placement_strategy = 'NetworkTopologyStrategy'
and strategy_options = {Analytics : 2}
and durable_writes = true;
---
# nodetool -h 10.2.29.38 repair -pr Keyspace1 Standard1
[2013-04-03 15:46:58,000] Starting repair command #1, repairing 1 ranges for
keyspace Keyspace1
[2013-04-03 15:47:00,881] Repair session b79b4850-9c75-11e2--8b5bf6ebea9e
for range (0,42535295865117307932921825928971026432] finished
[2013-04-03 15:47:00,881] Repair command #1 finished
root@ip-10-2-29-38:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,009 AntiEntropyService.java
(line 676) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] new session: will
sync a1/10.2.29.38, /10.46.113.236 on range
(0,42535295865117307932921825928971026432] for Keyspace1.[Standard1]
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,015 AntiEntropyService.java
(line 881) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] requesting merkle
trees for Standard1 (to [/10.46.113.236, a1/10.2.29.38])
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,202 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from /10.46.113.236
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,697 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from a1/10.2.29.38
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,879 AntiEntropyService.java
(line 1015) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Endpoints
/10.46.113.236 and a1/10.2.29.38 are consistent for Standard1
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 788) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Standard1 is fully
synced
INFO [AntiEntropySessions:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 722) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] session completed
successfully
root@ip-10-46-113-236:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropyStage:1] 2013-04-03 15:46:59,944 AntiEntropyService.java
(line 244) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Sending completed
merkle tree to /10.2.29.38 for (Keyspace1,Standard1)
root@ip-10-72-111-225:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
root@ip-10-72-111-225:/home/ubuntu#
---
# nodetool -h 10.46.113.236 repair -pr Keyspace1 Standard1
[2013-04-03 15:48:00,274] Starting repair command #1, repairing 1 ranges for
keyspace Keyspace1
[2013-04-03 15:48:02,032] Repair session dcb91540-9c75-11e2--a839ee2ccbef
for range
(42535295865117307932921825928971026432,127605887595351923798765477786913079296]
finished
[2013-04-03 15:48:02,033] Repair command #1 finished
root@ip-10-46-113-236:/home/ubuntu# grep dcb91540-9c75-11e2--a839ee2ccbef
/var/log/cassandra/system.log
INFO [AntiEntropySessions:5]
[jira] [Updated] (CASSANDRA-5424) nodetool repair -pr on all nodes won't repair the full range when a Keyspace isn't in all DC's
[
https://issues.apache.org/jira/browse/CASSANDRA-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-5424:
--
Attachment: (was: 5424-1.1.txt)
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
--
Key: CASSANDRA-5424
URL: https://issues.apache.org/jira/browse/CASSANDRA-5424
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.1.7
Reporter: Jeremiah Jordan
Assignee: Yuki Morishita
Priority: Critical
Fix For: 1.1.11
Attachments: 5424-1.1.txt
nodetool repair -pr on all nodes won't repair the full range when a Keyspace
isn't in all DC's
Commands follow, but the TL;DR of it, range
(127605887595351923798765477786913079296,0] doesn't get repaired between .38
node and .236 node until I run a repair, no -pr, on .38
It seems like primary arnge calculation doesn't take schema into account, but
deciding who to ask for merkle tree's from does.
{noformat}
Address DC RackStatus State LoadOwns
Token
127605887595351923798765477786913079296
10.72.111.225 Cassandra rack1 Up Normal 455.87 KB 25.00%
0
10.2.29.38 Analytics rack1 Up Normal 40.74 MB25.00%
42535295865117307932921825928971026432
10.46.113.236 Analytics rack1 Up Normal 20.65 MB50.00%
127605887595351923798765477786913079296
create keyspace Keyspace1
with placement_strategy = 'NetworkTopologyStrategy'
and strategy_options = {Analytics : 2}
and durable_writes = true;
---
# nodetool -h 10.2.29.38 repair -pr Keyspace1 Standard1
[2013-04-03 15:46:58,000] Starting repair command #1, repairing 1 ranges for
keyspace Keyspace1
[2013-04-03 15:47:00,881] Repair session b79b4850-9c75-11e2--8b5bf6ebea9e
for range (0,42535295865117307932921825928971026432] finished
[2013-04-03 15:47:00,881] Repair command #1 finished
root@ip-10-2-29-38:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,009 AntiEntropyService.java
(line 676) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] new session: will
sync a1/10.2.29.38, /10.46.113.236 on range
(0,42535295865117307932921825928971026432] for Keyspace1.[Standard1]
INFO [AntiEntropySessions:1] 2013-04-03 15:46:58,015 AntiEntropyService.java
(line 881) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] requesting merkle
trees for Standard1 (to [/10.46.113.236, a1/10.2.29.38])
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,202 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from /10.46.113.236
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,697 AntiEntropyService.java
(line 211) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Received merkle
tree for Standard1 from a1/10.2.29.38
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,879 AntiEntropyService.java
(line 1015) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Endpoints
/10.46.113.236 and a1/10.2.29.38 are consistent for Standard1
INFO [AntiEntropyStage:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 788) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Standard1 is fully
synced
INFO [AntiEntropySessions:1] 2013-04-03 15:47:00,880 AntiEntropyService.java
(line 722) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] session completed
successfully
root@ip-10-46-113-236:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
INFO [AntiEntropyStage:1] 2013-04-03 15:46:59,944 AntiEntropyService.java
(line 244) [repair #b79b4850-9c75-11e2--8b5bf6ebea9e] Sending completed
merkle tree to /10.2.29.38 for (Keyspace1,Standard1)
root@ip-10-72-111-225:/home/ubuntu# grep b79b4850-9c75-11e2--8b5bf6ebea9e
/var/log/cassandra/system.log
root@ip-10-72-111-225:/home/ubuntu#
---
# nodetool -h 10.46.113.236 repair -pr Keyspace1 Standard1
[2013-04-03 15:48:00,274] Starting repair command #1, repairing 1 ranges for
keyspace Keyspace1
[2013-04-03 15:48:02,032] Repair session dcb91540-9c75-11e2--a839ee2ccbef
for range
(42535295865117307932921825928971026432,127605887595351923798765477786913079296]
finished
[2013-04-03 15:48:02,033] Repair command #1 finished
root@ip-10-46-113-236:/home/ubuntu# grep dcb91540-9c75-11e2--a839ee2ccbef
/var/log/cassandra/system.log
INFO
[jira] [Created] (CASSANDRA-5452) Allow empty blob literals in CQL3
Sylvain Lebresne created CASSANDRA-5452:
---
Summary: Allow empty blob literals in CQL3
Key: CASSANDRA-5452
URL: https://issues.apache.org/jira/browse/CASSANDRA-5452
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.5
Attachments: 5452.txt
The current grammar don't allow empty blob literals (so '0x'). The goal here is
to allow the following syntax for that:
{noformat}
INSERT INTO test(k, b) VALUES (0, 0x)
{noformat}
I'll admit that '0x' is not the most beautiful syntax ever, but I think that's
the only thing that make sense.
I'll note that currently there is 2 workaround to insert empty blobs: you can
either use prepared statement (not a bad idea when using blobs anyway) or,
because we've deprecated but still support until 2.0 using strings as blob (to
allow upgrade from 1.2.0 to 1.2.1), you can use an empty string. I'll note that
this latter workaround will trigger a deprecation warning in the log however
and will stop working in 2.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] [Updated] (CASSANDRA-5452) Allow empty blob literals in CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5452:
Attachment: 5452.txt
Trivial patch attached.
Allow empty blob literals in CQL3
-
Key: CASSANDRA-5452
URL: https://issues.apache.org/jira/browse/CASSANDRA-5452
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.5
Attachments: 5452.txt
The current grammar don't allow empty blob literals (so '0x'). The goal here
is to allow the following syntax for that:
{noformat}
INSERT INTO test(k, b) VALUES (0, 0x)
{noformat}
I'll admit that '0x' is not the most beautiful syntax ever, but I think
that's the only thing that make sense.
I'll note that currently there is 2 workaround to insert empty blobs: you can
either use prepared statement (not a bad idea when using blobs anyway) or,
because we've deprecated but still support until 2.0 using strings as blob
(to allow upgrade from 1.2.0 to 1.2.1), you can use an empty string. I'll
note that this latter workaround will trigger a deprecation warning in the
log however and will stop working in 2.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-5418) streaming fails
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628239#comment-13628239
]
Igor Ivanov commented on CASSANDRA-5418:
It's the same column family. We're doing lot's of deletes for it.
Seems that assertion is caused by element written twice on ColumnIndexer block
boundary.
But column_index_size_in_kb is same on every node and set to default 64k.
streaming fails
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2, 1.2.3
Environment: 5 nodes, vnodes enabled, encryption disabled,
compression enabled, RackInferring snitch, Centos 6, Oracle JVM with JNA
enabled.
Reporter: Igor Ivanov
Priority: Critical
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
[jira] [Commented] (CASSANDRA-5452) Allow empty blob literals in CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628254#comment-13628254
]
Aleksey Yeschenko commented on CASSANDRA-5452:
--
+1
Allow empty blob literals in CQL3
-
Key: CASSANDRA-5452
URL: https://issues.apache.org/jira/browse/CASSANDRA-5452
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.5
Attachments: 5452.txt
The current grammar don't allow empty blob literals (so '0x'). The goal here
is to allow the following syntax for that:
{noformat}
INSERT INTO test(k, b) VALUES (0, 0x)
{noformat}
I'll admit that '0x' is not the most beautiful syntax ever, but I think
that's the only thing that make sense.
I'll note that currently there is 2 workaround to insert empty blobs: you can
either use prepared statement (not a bad idea when using blobs anyway) or,
because we've deprecated but still support until 2.0 using strings as blob
(to allow upgrade from 1.2.0 to 1.2.1), you can use an empty string. I'll
note that this latter workaround will trigger a deprecation warning in the
log however and will stop working in 2.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] [Updated] (CASSANDRA-5452) Allow empty blob literals in CQL3
[
https://issues.apache.org/jira/browse/CASSANDRA-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-5452:
-
Reviewer: iamaleksey
Allow empty blob literals in CQL3
-
Key: CASSANDRA-5452
URL: https://issues.apache.org/jira/browse/CASSANDRA-5452
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.2.1
Reporter: Sylvain Lebresne
Assignee: Sylvain Lebresne
Priority: Minor
Fix For: 1.2.5
Attachments: 5452.txt
The current grammar don't allow empty blob literals (so '0x'). The goal here
is to allow the following syntax for that:
{noformat}
INSERT INTO test(k, b) VALUES (0, 0x)
{noformat}
I'll admit that '0x' is not the most beautiful syntax ever, but I think
that's the only thing that make sense.
I'll note that currently there is 2 workaround to insert empty blobs: you can
either use prepared statement (not a bad idea when using blobs anyway) or,
because we've deprecated but still support until 2.0 using strings as blob
(to allow upgrade from 1.2.0 to 1.2.1), you can use an empty string. I'll
note that this latter workaround will trigger a deprecation warning in the
log however and will stop working in 2.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
git commit: replace LBQ with CLQ in RangeSliceResponseResolver
Updated Branches: refs/heads/trunk 576efcd81 - 4ab0dacad replace LBQ with CLQ in RangeSliceResponseResolver Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4ab0daca Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4ab0daca Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4ab0daca Branch: refs/heads/trunk Commit: 4ab0dacade95fcca81d032d5b23fb40d45606325 Parents: 576efcd Author: Jonathan Ellis jbel...@apache.org Authored: Wed Apr 10 16:32:05 2013 -0500 Committer: Jonathan Ellis jbel...@apache.org Committed: Wed Apr 10 16:32:42 2013 -0500 -- .../service/RangeSliceResponseResolver.java| 12 1 files changed, 8 insertions(+), 4 deletions(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/4ab0daca/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java -- diff --git a/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java b/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java index 1613b21..5ffcdbe 100644 --- a/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java +++ b/src/java/org/apache/cassandra/service/RangeSliceResponseResolver.java @@ -19,15 +19,19 @@ package org.apache.cassandra.service; import java.net.InetAddress; import java.util.*; -import java.util.concurrent.LinkedBlockingQueue; +import java.util.concurrent.ConcurrentLinkedQueue; + import com.google.common.collect.AbstractIterator; -import org.apache.cassandra.db.*; +import org.apache.cassandra.db.ColumnFamily; +import org.apache.cassandra.db.DecoratedKey; +import org.apache.cassandra.db.RangeSliceReply; +import org.apache.cassandra.db.Row; import org.apache.cassandra.net.AsyncOneResponse; import org.apache.cassandra.net.MessageIn; -import org.apache.cassandra.utils.Pair; import org.apache.cassandra.utils.CloseableIterator; import org.apache.cassandra.utils.MergeIterator; +import org.apache.cassandra.utils.Pair; /** * Turns RangeSliceReply objects into row (string - CF) maps, resolving @@ -45,7 +49,7 @@ public class RangeSliceResponseResolver implements IResponseResolverRangeSliceR private final String table; private ListInetAddress sources; -protected final CollectionMessageInRangeSliceReply responses = new LinkedBlockingQueueMessageInRangeSliceReply();; +protected final CollectionMessageInRangeSliceReply responses = new ConcurrentLinkedQueueMessageInRangeSliceReply(); public final ListAsyncOneResponse repairResults = new ArrayListAsyncOneResponse(); public RangeSliceResponseResolver(String table)
[jira] [Updated] (CASSANDRA-5418) streaming fails
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Ivanov updated CASSANDRA-5418:
---
Attachment: 5418-1.2.txt
Patch against branch 1.2
streaming fails
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2, 1.2.3
Environment: 5 nodes, vnodes enabled, encryption disabled,
compression enabled, RackInferring snitch, Centos 6, Oracle JVM with JNA
enabled.
Reporter: Igor Ivanov
Priority: Critical
Attachments: 5418-1.2.txt
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
{quote}
Then I see
[jira] [Updated] (CASSANDRA-5418) streaming fails
[
https://issues.apache.org/jira/browse/CASSANDRA-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-5418:
Reviewer: yukim
streaming fails
---
Key: CASSANDRA-5418
URL: https://issues.apache.org/jira/browse/CASSANDRA-5418
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.2.2, 1.2.3
Environment: 5 nodes, vnodes enabled, encryption disabled,
compression enabled, RackInferring snitch, Centos 6, Oracle JVM with JNA
enabled.
Reporter: Igor Ivanov
Priority: Critical
Attachments: 5418-1.2.txt
When I run *nodetool repair* on cas01 node it get's stuck at some point.
I see following exceptions in cas01 system.log:
{quote}
ERROR [Streaming to /10.10.45.60:28] 2013-04-02 09:03:55,353
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.60:28,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
ERROR [Thread-2076] 2013-04-02 09:07:12,261 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-2076,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-3660-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
{quote}
On other machines there are some exceptions too:
{quote}
ERROR [Thread-1424] 2013-04-02 09:07:12,248 CassandraDaemon.java (line 132)
Exception in thread Thread[Thread-1424,5,main]
java.lang.AssertionError: incorrect row data size 130921 written to
/var/lib/cassandra/data/EDITED/content_list/footballsite-content_list-tmp-ib-2268-Data.db;
correct is 131074
at
org.apache.cassandra.io.sstable.SSTableWriter.appendFromStream(SSTableWriter.java:285)
at
org.apache.cassandra.streaming.IncomingStreamReader.streamIn(IncomingStreamReader.java:179)
at
org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:122)
at
org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:238)
at
org.apache.cassandra.net.IncomingTcpConnection.handleStream(IncomingTcpConnection.java:178)
at
org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:78)
ERROR [Streaming to /10.10.45.58:55] 2013-04-02 09:07:12,263
CassandraDaemon.java (line 132) Exception in thread Thread[Streaming to
/10.10.45.58:55,5,main]
java.lang.RuntimeException: java.io.EOFException
at com.google.common.base.Throwables.propagate(Throwables.java:160)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
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)
Caused by: java.io.EOFException
at java.io.DataInputStream.readInt(Unknown Source)
at
org.apache.cassandra.streaming.FileStreamTask.receiveReply(FileStreamTask.java:193)
at
org.apache.cassandra.streaming.compress.CompressedFileStreamTask.stream(CompressedFileStreamTask.java:114)
at
org.apache.cassandra.streaming.FileStreamTask.runMayThrow(FileStreamTask.java:91)
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
... 3 more
{quote}
Then I see frozen status in *nodetool netstats* and
[Cassandra Wiki] Update of ContributorsGroup by DaveBrosius
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The ContributorsGroup page has been changed by DaveBrosius: http://wiki.apache.org/cassandra/ContributorsGroup?action=diffrev1=8rev2=9 * AdminGroup * AaronMorton * Alexis Wilke + * Ben McCann * ChrisBroome * EricEvans * ErnieHershey + * FlipKromer * gdusbabek + * JakeLuciani * JasonBrown * JoaquinCasares * LukasGutschmidt @@ -19, +22 @@ * MakiWatanabe * MarkWatson * MatthewDennis + * NickBailey + * Nick Neuberger + * PeterSchuller + * PrashantMalik * SergeRider * StephenConnolly + * StuHood * SylvainLebresne * thepaul * TylerHobbs
[jira] [Commented] (CASSANDRA-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628554#comment-13628554 ] nivance commented on CASSANDRA-5450: yes, I make one node configured, then tar the dir of cassandra, scp to the other three node. cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CASSANDRA-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628554#comment-13628554 ] nivance edited comment on CASSANDRA-5450 at 4/11/13 1:44 AM: - yes, I make one node configured, then tar the dir of cassandra, scp to the other three nodes. was (Author: nivance): yes, I make one node configured, then tar the dir of cassandra, scp to the other three node. cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- 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-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628592#comment-13628592 ] nivance commented on CASSANDRA-5450: It's my fault. The system tables of Every node is the same. The cluster run well after I delete the system tables in each node. Thks Williams. cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- 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] [Resolved] (CASSANDRA-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nivance resolved CASSANDRA-5450. Resolution: Fixed Fix Version/s: 1.2.0 config is wrong cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Fix For: 1.2.0 Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (CASSANDRA-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nivance updated CASSANDRA-5450: --- Comment: was deleted (was: config is wrong) cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Fix For: 1.2.0 Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- 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-5450) cluster : Host ID collision
[ https://issues.apache.org/jira/browse/CASSANDRA-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13628597#comment-13628597 ] Brandon Williams commented on CASSANDRA-5450: - You're welcome. cluster : Host ID collision --- Key: CASSANDRA-5450 URL: https://issues.apache.org/jira/browse/CASSANDRA-5450 Project: Cassandra Issue Type: Bug Components: Config Affects Versions: 1.2.0 Environment: centos-6-x86_64, jdk1.6.0_30, cassandra1.2.0 4 nodes, 2 datacenter, 2 nodes for each datacenter Reporter: nivance Labels: cluster Fix For: 1.2.0 Original Estimate: 1m Remaining Estimate: 1m I follow the guide Initializing a multiple node cluster in url: http://www.datastax.com/docs/1.2/initialize/cluster_init the exception occurs below when start the second node: java.lang.RuntimeException: Host ID collision between active endpoint /192.168.0.193 and /192.168.0.194 (id=4ebdbeea-2712-475b-a3e3-64b6e6b099a9) at org.apache.cassandra.locator.TokenMetadata.updateHostId(TokenMetadata.java:227) at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:1296) at org.apache.cassandra.service.StorageService.onChange(StorageService.java:1157) at org.apache.cassandra.service.StorageService.onJoin(StorageService.java:1895) at org.apache.cassandra.gms.Gossiper.handleMajorStateChange(Gossiper.java:805) at org.apache.cassandra.gms.Gossiper.applyStateLocally(Gossiper.java:883) at org.apache.cassandra.gms.GossipDigestAck2VerbHandler.doVerb(GossipDigestAck2VerbHandler.java:43) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56) 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) I track the source code. the function getHostId in class org.apache.cassandra.gms.Gossiper, diff endpoint it returns the same value,like: /192.168.0.1944ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.88 c375010a-c464-40c9-a7db-61de319a4cba /192.168.3.21 4ebdbeea-2712-475b-a3e3-64b6e6b099a9 /192.168.0.1934ebdbeea-2712-475b-a3e3-64b6e6b099a9 so, the exception occurs. Is it a bug or is my Configuration wrong? -- 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
