[
https://issues.apache.org/jira/browse/CASSANDRA-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208600#comment-13208600
]
Edward Capriolo edited comment on CASSANDRA-3677 at 2/15/12 5:32 PM:
---------------------------------------------------------------------
It seems wrong to abandon hints. Arguments like such as "(unless you wrote at
ANY, in which case you've already lived dangerously.)" are a slippery slope,
and it says something about the contract of ANY.
According to Cassandra.thrift.
{quote}
* ANY Ensure that the write has been written once somewhere,
including possibly being hinted in a non-target node.
{quote}
It does not say :
{quote}
* ANY Ensure that the write has been written once somewhere,
including possibly being hinted in a non-target node, which probably wont get
lost, unless .....
{quote}
Maybe there is some other harder to contrive scenario out there RF3, write ONE,
two hints and one node failure then a move also causes an issue with lost hints.
It is an edge case, but I think it is important. Since writes are idempotent I
would rather a hint gets delivered causing an extra write then it gets lost.
1.0's made HH way more reliable, I would like to see Cassandra push that high
standard and not have caveats associated around how ANY works.
was (Author: appodictic):
It seems wrong to abandon hints. Arguments like such as "(unless you wrote
at ANY, in which case you've already lived dangerously.)" are a slippery
slope, and it says something about the contract of ANY.
According to Cassandra.thrift.
{quote}
* ANY Ensure that the write has been written once somewhere,
including possibly being hinted in a non-target node.
{quote}
It does not say :
{quote}
* ANY Ensure that the write has been written once somewhere,
including possibly being hinted in a non-target node, which probably wont get
lost, unless .....
{quote}
Maybe there is some other harder to contrive scenario out there RC3, write ONE,
two hints and one node failure then a move also causes an issue with lost hints.
It is an edge case, but I think it is important. Since writes are idempotent I
would rather a hint gets delivered causing an extra write then it gets lost.
1.0's made HH way more reliable, I would like to see Cassandra push that high
standard and not have caveats associated around how ANY works.
> NPE during HH delivery when gossip turned off on target
> -------------------------------------------------------
>
> Key: CASSANDRA-3677
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3677
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.0.7
> Reporter: Radim Kolar
> Assignee: Brandon Williams
> Priority: Trivial
> Fix For: 1.0.8
>
> Attachments: 3677-v1.patch, 3677.txt
>
>
> probably not important bug
> ERROR [OptionalTasks:1] 2011-12-27 21:44:25,342 AbstractCassandraDaemon.java
> (line 138) Fatal exception in thread Thread[OptionalTasks:1,5,main]
> java.lang.NullPointerException
> at
> org.cliffc.high_scale_lib.NonBlockingHashMap.hash(NonBlockingHashMap.java:113)
> at
> org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:553)
> at
> org.cliffc.high_scale_lib.NonBlockingHashMap.putIfMatch(NonBlockingHashMap.java:348)
> at
> org.cliffc.high_scale_lib.NonBlockingHashMap.putIfAbsent(NonBlockingHashMap.java:319)
> at
> org.cliffc.high_scale_lib.NonBlockingHashSet.add(NonBlockingHashSet.java:32)
> at
> org.apache.cassandra.db.HintedHandOffManager.scheduleHintDelivery(HintedHandOffManager.java:371)
> at
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:356)
> at
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:84)
> at
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:119)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
