SVGImageElementBridge and closing url connections

[Lukasz Matuszczak <l....@atrem.pl>]

Hello,

I've noticed a strange behaviour of batik considering URL Connections. I've made 
my own java protocol handler, and I can see that method getInputStream() of my 
ResourceURLConnection object is called, but the stream is never closed if it is 
used by SVGImageElementBridge.

I looked into createImageGraphicsNode os SVGImageElementBridge implementation 
and I think there is a bug there. The stream is wrapped in ProtectedStream 
object 'reference'. However reference.release() is called only if we get to the 
last "try ... finally" (image is raster and ImageTagRegistry is allowed to open 
URL). If the image is SVG the new GraphicsNode is returned and the 'reference' 
is not released.

I would like to know is it a bug or an expected behaviour? I think there are 
many places where external resources can be loaded into batik, so maybe there 
are other classes where similar bug can occur.

Regards,
Lukasz Matuszczak 



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: SVGImageElementBridge and closing url connections

[Lukasz Matuszczak <l....@atrem.pl>]

>[...]
>   Somewhere between the two.  We should close the stream when we know we
> are done with it to help the system reclaim resources sooner but I don't
> think this is a full out bug.  I'll fix it anyway as it's easy to fix
> and I agree it's ugly.
> [...]


Thanks for you help. Of course you are right that there is no rule that you must 
call 'close' but as you said it is nice to call it to free all unused resources 
sooner. Otherwise for example files and sockets remain open until GC activates 
and call 'finalize' methods of such classes as FileInputStream or SocketImpl. My 
InputStream subclass also calls 'close' from 'finalize' so I agree that there is 
no memory leak, but as my protocol handler can open only one InputStream at the 
same time, everything works very slowly.

Regards,
Lukasz Matuszczak 



---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: SVGImageElementBridge and closing url connections

[th...@kodak.com]

"Lukasz Matuszczak" <l....@atrem.pl> wrote on 05/09/2006 07:29:17 
AM:

> I've noticed a strange behaviour of batik considering URL Connections. 
I've made 
> my own java protocol handler, and I can see that method getInputStream() 
of my 
> ResourceURLConnection object is called, but the stream is never closed 
if it is 
> used by SVGImageElementBridge.
> 
> I looked into createImageGraphicsNode os SVGImageElementBridge 
implementation 
> and I think there is a bug there. The stream is wrapped in 
ProtectedStream 
> object 'reference'. However reference.release() is called only if we get 
to the 
> last "try ... finally" (image is raster and ImageTagRegistry is allowed 
to open 
> URL). If the image is SVG the new GraphicsNode is returned and the 
'reference' 
> is not released.

   Well the reference _is_ released but you are correct that we don't call
'release()' on it.  Eventually this object will go to GC since all 
references 
to it are cleared, however if your class _requires_ that 'close' be called 
for
proper operation this might be a problem (in this case I would argue that 
the
bug was with your implementation of InputStream not our usage).

> I would like to know is it a bug or an expected behavior?

   Somewhere between the two.  We should close the stream when we know we
are done with it to help the system reclaim resources sooner but I don't
think this is a full out bug.  I'll fix it anyway as it's easy to fix
and I agree it's ugly.

> I think there are many places where external resources can be loaded 
into 
> batik, so maybe there are other classes where similar bug can occur.

   This may be but as I say above I don't think the InputStream interface
requires that close be called for proper operation.  It is nice to call 
close
as soon as you can but nothing should break as long as all references to 
the
stream are cleared.  I am fairly confident that we clear references to 
streams
as otherwise we would have memory leaks and at least in released versions 
we
have done some fairly extensive testing to ensure there aren't (even very
small ones).


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org