Process enqueued messages from the NAI synchronously.
As ConnectivityService is ready to accept messages about a network
agent, it should process messages immediately and before messages
from other agents are processed.
This is because of minute ordering issues between the agent process,
ConnectivityService and the network stack. In particular, as the agent
is created, ConnectivityService requests the NetworkMonitor from the
network stack ; while this is happening, the process creating the
agent may have sent a bunch of other messages... including, but not
limited to, disconnects or creation of other agents.
The operative case is the case where a disconnect is in the queue.
agent1.register
→ CS creates the monitor for agent 1
agent1.unregisterAfterReplacement
→ CS enqueues in agent1 pending creation of the monitor
agent2.register
→ CS creates the monitor for agent 2
monitor for agent 1 is created
→ CS posts a message to complete agent 1 creation
monitor for agent 2 is created
→ CS posts a message to complete agent 2 creation
agent 1 creation completes
→ CS re-posts the unregisterAfterReplacement message
agent 2 creation completes
...and this is where things fail, because unregistering agent 1
isn't processed yet. If they use the same interface (which is
a common use case for unregisterAfterReplacement) then this
creation will fail.
To address this, this patch will process all agent1 messages
synchronously as the creation completes. It will solve the case
above, and it passes all tests for early network creation.
However, it is worth noting that this is not actually correct,
because it does not guarantee that all messages are processed
in order. Namely, two agents have separate queues and
therefore if they send interleaved messages while CS is
waiting for the NetworkMonitor to be created, the order of
these messages will be lost. e.g.
agent1.register
agent2.register
agent1.unregisterAfterReplacement
The case above SHOULD fail if the agents have the same
interface, but with this patch it will likely succeed because
the call to agent1.unregisterAfterReplacement will be received
while the two NetworkMonitor are being created, and then
be processed as agent1 finishes registration.
The correct change, therefore, would really enqueue all
messages when *any* agent (of the same process at least)
is being created. However, it is arguable whether it's worth
building that change over this one, and it is even arguable
whether the behavior of this here change might not be
better, insofar as two agent messages are generally
unrelated to each other except for unregistering.
Test: CtsNetTestCases ConnectivityCoverageTests
Change-Id: Idf75e4e96c67a456cf0979a79321603b46e8c99c
2 files changed