I've noticed that the scim2-sdk-client does not completely consume result entity data from client operations. The effect is that the underlying TCP stream is automatically closed after each operation. A new TCP stream must be re-negotiated for a subsequent request. This is all automatic under Jersey, but it causes a delay that is especially noticeable when any of these things are true:
there are many client requests
TLS is used to secure the connection
there is significant latency to the target server.
This can be reproduced with this client code:
ScimService scimService = new ScimService(target);
for (int i = 0; i < 100; i++) {
UserResource newUser = new UserResource().setUserName("createLoopUser" + i);
UserResource createdUser = scimService.createRequest("Users", newUser).
contentType(MediaType.APPLICATION_JSON).invoke();
Assert.assertNotNull(createdUser);
}
This code will complete without errors, but you can observe the unnecessary network activity by examining a wireshark trace of the TCP/IP network communications.
I've noticed that the scim2-sdk-client does not completely consume result entity data from client operations. The effect is that the underlying TCP stream is automatically closed after each operation. A new TCP stream must be re-negotiated for a subsequent request. This is all automatic under Jersey, but it causes a delay that is especially noticeable when any of these things are true:
This can be reproduced with this client code:
This code will complete without errors, but you can observe the unnecessary network activity by examining a wireshark trace of the TCP/IP network communications.