Methods of the type receiveMapNotify() pass the raw packet to a specific
deserializer without checking if the packet is actually of the correct
type. Deserializers expect checking to happen outside, and deserialize
anyway. In some cases, they even succeed without throwing an exception,
with erroneous results. This is obviously bad.
This patch fixes the serializers to throw an exception when the wrong
packet type is passed for deserialization. It also makes the
receiveXXX() methods in the IT to retry until they receive the expected
packet type.
In some cases, a Map-Register can cause an SMR to be sent. SMRs are sent
in a separate thread. This may lead to a race condition beween the
Map-Notify sent back to the xTR and the SMR sent to the subscriber. In
some cases, we expect a Map-Notify, but deserialize an SMR as a
Map-Notify, if it comes first. We had IT fail in the past with a message
of the type:
MappingServiceIntegrationTest.testLCAFs:357->registerAndQuery__SrcDestLCAF:1828->registerAddressAndQuery:1789 expected:<8> but was:<-
859317697383733792>
This patch finally fixes that.
It needs to disable testRepeatedSmr() though, because the test is
broken, and it never actually worked as intended. It will be fixed in a
future commit.
Change-Id: Ife4396013df82cb6320978c3c02536df91fba646
Signed-off-by: Lorand Jakab <lojakab@cisco.com>