[keycloak-dev] Remember to close responses using admin client
Stian Thorgersen
sthorger at redhat.com
Mon Oct 24 00:26:26 EDT 2016
Maybe there is a way (or we can send a PR) to make RestEasy client return
location as a string for a method?
On 21 October 2016 at 14:51, Stan Silvert <ssilvert at redhat.com> wrote:
> On 10/21/2016 6:09 AM, Marek Posolda wrote:
> > On 21/10/16 08:18, Stian Thorgersen wrote:
> >> For methods on the admin client that return a Response it's important to
> >> remember to close it. Failing to do this causes:
> >>
> >> * Not freeing up connections
> >> * Tests can fail intermittently as the tx may not be completed before
> you
> >> move on
> >>
> >> Ideal would be to find a way to prevent this and have the admin client
> >> close the responses, but I don't think that's possible.
> > Maybe we already discuss, that we can possibly avoid using "Response"
> > object at most admin client operations.
> >
> > We typically use them in "create" methods (POST requests). So if we
> > refactor server-side to return the actual created object with filled ID,
> > we can use something like:
> >
> > ClientRepresentation createdClient =
> > realmResource.clients().create(clientRepresentation);
> > String createdUuid = createdClient.getId();
> >
> > instead of current:
> >
> > Response response = realm.clients().create(rep);
> > response.close();
> > String createdUuid = ApiUtil.getCreatedId(response);
> >
> >
> > The advantages is that:
> > - No need to care about closing response
> > - Better exception handling - instead of checking response status etc,
> > the new code will throw exception directly. Which is usually cleaner
> > - You don't need to send separate GET request to retrieve newly created
> > client. And in most cases, you usually want newly created client
> >
> > The possible disadvantage:
> > - The POST response is bigger as it contains representation of newly
> > created client. However you probably usually need the new client anyway.
> > Not sure if it's possible to set admin console (angular) to avoid
> > sending separate GET request when the entity was already retrieved
> > through POST, but I suppose that yes.
> >
> > Marek
> Anything is possible, but that's not what is expected from a POST
> request. From RFC-7231:
>
> If one or more resources has been created on the origin server as a
> result of successfully processing a POST request, the origin server
> SHOULD send a 201 (Created) response containing a Location header
> field that provides an identifier for the primary resource created
> (Section 7.1.2 <https://tools.ietf.org/html/rfc7231#section-7.1.2>)
> and a representation that describes the status of the
> request while referring to the new resource(s).
>
> So basically, the expected result is the identifier of the created
> resource and not the resource itself.
>
> Maybe the problem can be solved by letting the admin client cache the
> responses before returning them to the caller. Then our test harness
> can clean them up.
> >
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list