p2p push behaviour

[toolslive]

In p2p push from drive A to drive B, if a key is specified in the list to push,
but not present at A, there is no exception, it's just skipped.
Is this intended behaviour? (we tested the simulator, will test the real thing shortly)

[jphughes]

This is a bug in the simulator. We will look at this and let you know.

On Oct 1, 2014, at 2:25 AM, Romain Slootmaekers notifications@github.com wrote:

In p2p push from drive A to drive B, if a key is specified in the list to push,
but not present at A, there is no exception, it's just skipped.
Is this intended behaviour? (we tested the simulator, will test the real thing shortly)

—
Reply to this email directly or view it on GitHub.

[chiaming2000]

For protocol 2.x, there is a bug such that the overall status always return true with PeerToPeerOperation.getStatus() if all the operations can be processed (failed/succeeded). This is fixed with the commit mentioned below.

A KineticException is thrown only when the operations specified CAN NOT be processed and errors cannot be properly handled by the drive/simulator. If all the operations can be processed (failed or succeeded), the overall status is set in the response message (the returned PeerToPeerOperation object).

The overall status is set to true if and only if each of the specified operation was processed successfully. Otherwise, it is set to false.

Applications can check individual operation's status by examining each Operation's status with the returned PeerToPeerOperation.getOperationList() API.

The following commit enforced/enhanced the above behavior (protocol 3.x):
2015a63

An example is at the link here (test case "testP2PPut_Fails_ForVersionMismatch"):

https://github.com/Seagate/kinetic-java/blob/master/kinetic-test/src/test/java/com/seagate/kinetic/simulator/client/p2p/PeerToPeerOperationTest.java