Hi Alex, This looks like useful clean-up to do. I've applied your patch to HttpServerCall and done a similar task when writing request entities via HTTP clients.
Could you do some tests and confirm that this does help? Best regards, Jerome > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la > part de Alex Milowski > Envoyé : samedi 24 novembre 2007 19:35 > À : [email protected] > Objet : Re: Releasing Representation > > On 11/23/07, Alex Milowski <[EMAIL PROTECTED]> wrote: > > I see there is a release() method on the Representation > class but I can find any > > place in the trunk where this method is actually used. > > > > I have a problem in that I'm using an OutputRepresentation > instance to return > > a resource from eXist but I need to ensure that the read > lock on that > > resource is > > always released. If not, things will eventually lock up. > > Looking into this, I think the following patch will do what I want: > > Index: HttpServerCall.java > =================================================================== > --- HttpServerCall.java (revision 2263) > +++ HttpServerCall.java (working copy) > @@ -320,6 +320,7 @@ > */ > public void sendResponse(Response response) throws IOException { > if (response != null) { > + try { > writeResponseHead(response); > Representation entity = response.getEntity(); > > @@ -343,6 +344,12 @@ > if (getResponseEntityStream() != null) { > getResponseEntityStream().flush(); > } > + } finally { > + Representation entity = response.getEntity(); > + if (entity!=null) { > + entity.release(); > + } > + } > } > } > > > This patch guarantees that release will always be called on a response > regardless of whether write() is called or whether there is an > IOException. This means that the > life-cycle of a Representation instance in a response always ends with > a release() call. > > I'm testing this now to see if this clears up my resource > locking/release issues with my > eXist integration. > > --Alex Milowski
