Something is slowing down the accomplishment of subscription requests.
This is put into evidence by the compound requests:
After the log of:
<Subrequest 1: ....
<Subrequest 2: ....
<Subrequest 3: ....
in a normal case, you should see
<Controlling session: ....
<Controlling session: ....
<Controlling session: ....
in rapid sequence.
However, in your case, after the first occurrence, there is a significant time gap.
Such delays may cause the client to reissue some subscription requests
(just in case they got lost) until it eventually gets an answer.
The observed delays must have been introduced by some calls to the Metadata Adapter or in the "subscribe" calls to the Data Adapter.
In the forthcoming (3.6) release, the Server will be more robust to delays in Adapter calls;
for now, you should ensure that most of them don't introduce delays,
by following the guidelines suggested in the Adapter javadocs.