[
https://issues.apache.org/jira/browse/CASSANDRA-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053571#comment-14053571
]
Jason Brown edited comment on CASSANDRA-7496 at 7/7/14 11:57 AM:
-----------------------------------------------------------------
[~tjake] I produced this by building a 3 node cluster in ccm. Then I ran
'stress write' to get some data into the cluster (with RF=2), calling flush
every tens seconds so I could monitor the amount of data per node (didn't need
much data, just something to play with). Then I ran
{code}ccm node1 nodetool repair Keyspace1 Standard1{code}
, node1 would get the exception in under 30 seconds (usually occurring a few
times during the span over the repair).
As I was testing out some changes I'm working on, I don't believe the cause of
the messages timing out during repair is a problem in 2.1 (just my own bugs to
work out on my branch).
was (Author: jasobrown):
[~tjake] I produced this by building a 3 node cluster in ccm. Then I ran
'stress write' to get some data into the cluster (with RF=2), calling flush
every tens seconds so I could monitor the amount of data per node (didn't need
much data, just something to play with). Then I ran {code}ccm node1 nodetool
repair Keyspace1 Standard1{code}; node1 would get the exception in under 30
seconds (usually occurring a few times during the span over the repair).
As I was testing out some changes I'm working on, I don't believe the cause of
the messages timing out during repair is a problem in 2.1 (just my own bugs to
work out on my branch).
> ClassCastException in MessagingService
> --------------------------------------
>
> Key: CASSANDRA-7496
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7496
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: 3 node ccm cluster running in a linux VM on my laptop
> Reporter: Jason Brown
> Assignee: Jason Brown
> Fix For: 2.1.0
>
> Attachments: 7496.txt
>
>
> Got the following exception when running repair on a 3 node ccm cluster
> {code}
> ERROR [EXPIRING-MAP-REAPER:1] 2014-07-03 21:24:33,063
> CassandraDaemon.java:166 - Exception in thread
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.ClassCastException: org.apache.cassandra.net.CallbackInfo cannot be
> cast to org.apache.cassandra.net.WriteCallbackInfo
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:352)
> ~[main/:na]
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:335)
> ~[main/:na]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98)
> ~[main/:na]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:75)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_60]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]
> {code}
> Looks like that block (MessagingService, li. 352), was changed with
> CASSANDRA-7245.
> While I produced this on trunk, I compared the MS code on trunk with 2.1.0
> and it is the same. This is the change that 7245 introduced:
> pre-7245
> {code}
> if (expiredCallbackInfo.shouldHint())
> {
> Mutation mutation = (Mutation) ((WriteCallbackInfo)
> expiredCallbackInfo).sentMessage.payload;
> return StorageProxy.submitHint(mutation,
> expiredCallbackInfo.target, null);
> }
> {code}
> 7245:
> {code}
> Mutation mutation = (Mutation) ((WriteCallbackInfo)
> expiredCallbackInfo).sentMessage.payload;
> try
> {
> if (expiredCallbackInfo.shouldHint())
> {
> return StorageProxy.submitHint(mutation,
> expiredCallbackInfo.target, null);
> }
> }
> finally
> {
> //We serialized a hint so we don't need this mutation
> anymore
> mutation.release();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
