[CONTROLLER-713] Clustering : NPE on startup Created: 20/Aug/14  Updated: 05/Sep/14  Resolved: 05/Sep/14

Status: Resolved
Project: controller
Component/s: mdsal
Affects Version/s: Helium
Fix Version/s: None

Type: Bug
Reporter: Moiz Raja Assignee: Moiz Raja
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: PC

Issue Links:
Duplicate
is duplicated by CONTROLLER-712 Shard Actor (Raft) applyState results... Resolved
External issue ID: 1595
Priority: Low

 Description   

Steps to reproduce
-------------------
1. Start a single controller node with clustering enabled
2. Connect mininet to the controller
3. On the controller console press CTRL+C to exit
4. Exit mininet
5. Start the controller again

You will see the following exception show up.

2014-08-19 21:59:02 PDT [com.google.common.util.concurrent.Futures$ImmediateFuture] SEVERE com.google.common.util.concurrent.Futures$ImmediateFuture addListener RuntimeException while executing runnable com.google.common.util.concurrent.Futures$4@6d11edc3 with executor com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService@3410d526
java.lang.NullPointerException
at org.opendaylight.controller.cluster.datastore.Shard$2.onSuccess(Shard.java:273)
at org.opendaylight.controller.cluster.datastore.Shard$2.onSuccess(Shard.java:271)
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1149)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293)
at com.google.common.util.concurrent.Futures$ImmediateFuture.addListener(Futures.java:99)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1152)
at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1088)
at org.opendaylight.controller.cluster.datastore.Shard.commit(Shard.java:271)
at org.opendaylight.controller.cluster.datastore.Shard.applyState(Shard.java:369)
at org.opendaylight.controller.cluster.raft.RaftActor.onReceiveCommand(RaftActor.java:163)

 Comments   
Comment by Moiz Raja [ 20/Aug/14 ]

One possible reason for this is that the initial transaction that is done by the topology manager matches the entry from the recovery log due to which a cohort is found in the map that the shard maintains.

A possible fix may be to add a timestamp to each modification to distinguish it from the other.

Comment by Moiz Raja [ 29/Aug/14 ]

https://git.opendaylight.org/gerrit/#/c/10512/

Generated at Wed Feb 07 19:53:41 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.