[ 
https://issues.apache.org/jira/browse/CASSANDRA-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13208600#comment-13208600
 ] 

Edward Capriolo commented on CASSANDRA-3677:
--------------------------------------------

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

        

Reply via email to