Indeed, though
notifyUser cannot be disallowed to take some time to gather profile information, a block of several seconds would cause conflicts with the client mechanisms of recovery against unresponsive connections (which involves the reconnection attempts you noticed).
Your example with fixed pauses, however, may be misleading, because we should expect that user profile data, once obtained and cached, can be retrieved instantly by subsequent calls of
notifyUser.
Hence, the connection request might fail the first few times, but eventually succeed.
From the application point of view, this is not much different from a connection request that stays pending for long time until it gets an answer.
One important difference is that the Stream-sense mechanism is triggered and polling requests may be mixed to streaming requests (which may involve the different parameters you noticed).
If the first fast execution of
notifyUser should correspond to a polling attempt, then a polling session might be established where a streaming session could have been possible.
You could prevent the case by enabling the recovery of slow-starting streaming connections; see
setBufferedStreamingHandled.
Another important difference is, as you noticed, that multiple sessions are created.
However, all those session (but for the last one) are short lived and do not yield any data.
Unfortunately, this sort of handshaking phase consumes some resources and some log space.
Is there any aspect of the matter that causes blocking problems in your scenario?
