Rebuilding TPCLog

[baugarten]

java.lang.NullPointerException
    at edu.berkeley.cs162.TPCLog.rebuildKeyServer(TPCLog.java:155)
    at edu.berkeley.cs162.IntegrationBase$3.run(IntegrationBase.java:99)
    at java.lang.Thread.run(Thread.java:680)
Exception in thread "Thread-3" java.lang.AssertionError
    at org.junit.Assert.fail(Assert.java:92)
    at org.junit.Assert.assertTrue(Assert.java:43)
    at org.junit.Assert.assertTrue(Assert.java:54)
    at edu.berkeley.cs162.IntegrationBase$3.run(IntegrationBase.java:105)
    at java.lang.Thread.run(Thread.java:680)

[baugarten]

Do we have any tests for the TPCLog?

I don't think rebuilding from a log file works at all

[mqphan]

At the beginning, the log is empty, so interruptedTpcOperation is null. That's makes the null pointer exception

[ducky64]

Don't we need unit tests for EVERYTHING? Especially since the autograder is MIA...

[mqphan]

The NullPointerException does not happen to me. That's weird

[baugarten]

No, its null if there are multiple commits/aborts in a row for different TPC operations.

[chungfai]

so how we handle multiple commits/aborts in a row ?

[chungfai]

so is it for extra credit or what....????
this one https://piazza.com/class#spring2013/cs162/848 ?
or the part4 is totally wrong?

[mqphan]

TpcMaster makes sure that it sends a commit/abort after it sends a put/del
req to a slave. To do that, each slaveInfo has a lock. It locks the whole 2
phases of TPC.
Although this solution has less parallelized stuff, but it is the simplest
one. TPCMasterHandler does not need to change.

On Saturday, May 11, 2013, steventsim wrote:

so how we handle multiple commits/aborts in a row ?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-17765191
.

[mqphan]

Extra credit has 2 questions: 5 & 6.
Q5. Contact the slaves concurrently. We do have this in TPCMaster.
Q6. Serve put/del req concurrently. Right now we dont have this. To do
this, TPCMasterHandler and TPCLog need to be reimplented to receive mutiple
put/del req in a row. Considering the time and work, I vote to not do this.
What do you think?

On Saturday, May 11, 2013, steventsim wrote:

so is it for extra credit or what....????
this one https://piazza.com/class#spring2013/cs162/848 ?
or the part4 is totally wrong?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-17765995
.

[ducky64]

Yeah, forget about it unless you have tons of time.

[mqphan]

If I am not mistaken, we still have one more slip day after today. Correct me if I'm wrong.
Any way, if we are gonna do question 6, here is my proposal to changes:

1. TPCMasterHandler has a hashMap named masterUnDecided<Long TPCOperationId, KVMessage request>. Every put/del request is added to the hashMap. When a slave receives a decision from the master, it checks the hashMap to get the correct request according to the TPCOpId in the decision, do the operation, send the ack to the master successfully, then remove the TPCOperationId key from the hashMap. Of course, there should be a lock for the hashMap because of multiple threads running on the slaves.
2. TPCLog also has a hashMap<Long TPCOperationId, KVMessage request> along side the "entries" list. In rebuildKeyServer(), loop over "entries" and add every put/del request to the hashMap. During the loop, when sees a commit/abort message, get the request from the hashMap based on TPCOperationId, do the appropriate operation, and finally remove the TPCOperationId from the hashMap. Because there are multiple threads running on the slave now, there should be a lock for TPCLog inside TPCMasterHandler.
3. In TPCMaster, there is no need to lock the slaveInfo in performTPCOperation and handleGet.
   What do you think? Anything I miss?

[mqphan]

Acutally, there is only 1 hashMap needed, and it resides in TPCLog. TPCMasterHandler uses the hashMap of TPCLog.