You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2002/02/18 09:52:56 UTC
static/threading problem with SVGFontUtilities
Hi,
I have a couple of problems with the SVGFontUtilities class.
It holds a static reference to the "current" document.
This means that it will hold onto the last document to have text in it. I
ran into a problem where the document was holding onto a whole lot of
other stuff through the DefaultSVGContext due to anonymous inner class
using variables in the outer class.
This appears to be a memory leak of sorts.
The other problem is that the code would appear to not be thread safe. In
a multi-threaded environment the "current" document will constantly be
changing and the variable 'fontFamilyMap' will be changed all the time. It
could also have more than one thread altering the hashmap which would
cause an exception.
The method is only used in one place that I could find in
SVGTextElementBridge.java.
One solution could be to store the 'fontFamilyMap' in the document. No
static references and only a thread problem if two threads are handling
the same document which can be solved by making the hashmap synchronized.
Thanks for the good work so far.
Thanks,
Keiron
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Vincent Hardy <vi...@sun.com>.
Keiron,
I will have a look at your test case as the error below does not show
where the exception is happening.
Cheers,
V.
Keiron Liddle wrote:
>
> Hi Vincent,
>
> The memory thing is better thanks. It appears there can still be some
> threading thing but it is very rare (after about 12000 documents in heavy
> use).
> java.lang.NullPointerException
> at org.apache.batik.bridge.SVGFontUtilities.getFontFamily(Unknown
> Source)
>
> Using the testing that I sent in this email:
> http://marc.theaimsgroup.com/?l=batik-dev&m=100860672129140&w=2
> Is the way the code works valid?
>
> The problem that I encountered there (the style parsing error) I was able
> to solve by putting a static synchronization around the lines 402 - 404 in
> CSSOMStyleDeclaration.
>
> Thanks,
> Keiron.
>
> On 2002.02.20 22:49 Vincent Hardy wrote:
> > Keiron,
> >
> > There is a fix in the CVS repository.
> > Cheers,
> > V.
> >
> > Keiron Liddle wrote:
> > >
> > > Hi,
> > >
> > > I have a couple of problems with the SVGFontUtilities class.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Thierry Kormann <tk...@ilog.fr>.
Keiron Liddle wrote:
> Hi Vincent,
>
> No. It is a new BridgeContext every time a document is processed.
> I had a look at it and it seems to me that the problem could be:
> In BridgeContext
> One thread is at line 225, so that thread knows the fontFamilyMap is not
> null.
> Another thread then goes through line 250 and sets the fontFamilyMap to
> null. Since fontFamilyMap is static and common to both threads.
> The first thread then returns null.
I suggest we remove the static modifier on fontFamilyMap in BridgeContext
such as a new font family Map is created per document (ie per BridgeContext).
Any comments?
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Vincent Hardy <vi...@sun.com>.
Keiron,
Ooops, the static modifier is a cut/paste error on my part.
I'll fix this.
V.
Keiron Liddle wrote:
>
> Hi Vincent,
>
> No. It is a new BridgeContext every time a document is processed.
> I had a look at it and it seems to me that the problem could be:
> In BridgeContext
> One thread is at line 225, so that thread knows the fontFamilyMap is not
> null.
> Another thread then goes through line 250 and sets the fontFamilyMap to
> null. Since fontFamilyMap is static and common to both threads.
> The first thread then returns null.
>
> Keiron.
>
> On 2002.02.21 04:19 Vincent Hardy wrote:
> > Keiron,
> >
> > Are you sharing your BridgeContext between threads by
> > any chance? I think somehow the BridgeContext used by SVGFontUtilities
> > is used by another thread which must set the context's Document
> > in the middle of the getFontFamilyMap execution which then returns
> > null.
> >
> > Vincent.
> >
> > Keiron Liddle wrote:
> > >
> > > It seems a bit rarer than I thought.
> > >
> > > Stack trace with line numbers:
> > >
> > ...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: batik-dev-help@xml.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi Vincent,
No. It is a new BridgeContext every time a document is processed.
I had a look at it and it seems to me that the problem could be:
In BridgeContext
One thread is at line 225, so that thread knows the fontFamilyMap is not
null.
Another thread then goes through line 250 and sets the fontFamilyMap to
null. Since fontFamilyMap is static and common to both threads.
The first thread then returns null.
Keiron.
On 2002.02.21 04:19 Vincent Hardy wrote:
> Keiron,
>
> Are you sharing your BridgeContext between threads by
> any chance? I think somehow the BridgeContext used by SVGFontUtilities
> is used by another thread which must set the context's Document
> in the middle of the getFontFamilyMap execution which then returns
> null.
>
> Vincent.
>
> Keiron Liddle wrote:
> >
> > It seems a bit rarer than I thought.
> >
> > Stack trace with line numbers:
> >
> ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Vincent Hardy <vi...@sun.com>.
Keiron,
Are you sharing your BridgeContext between threads by
any chance? I think somehow the BridgeContext used by SVGFontUtilities
is used by another thread which must set the context's Document
in the middle of the getFontFamilyMap execution which then returns
null.
Vincent.
Keiron Liddle wrote:
>
> It seems a bit rarer than I thought.
>
> Stack trace with line numbers:
>
...
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Keiron Liddle <ke...@aftexsw.com>.
It seems a bit rarer than I thought.
Stack trace with line numbers:
svg graphic could not be built: null
java.lang.NullPointerException
at
org.apache.batik.bridge.SVGFontUtilities.getFontFamily(SVGFontUtilities.java:60)
at
org.apache.batik.bridge.SVGTextElementBridge.getAttributeMap(SVGTextElementBridge.java:1091)
at
org.apache.batik.bridge.SVGTextElementBridge.buildAttributedStrings(SVGTextElementBridge.java:422)
at
org.apache.batik.bridge.SVGTextElementBridge.buildAttributedString(SVGTextElementBridge.java:346)
at
org.apache.batik.bridge.SVGTextElementBridge.buildGraphicsNode(SVGTextElementBridge.java:204)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:190)
at
org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:148)
at
org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(GVTBuilder.java:188)
at
org.apache.batik.bridge.GVTBuilder.buildComposite(GVTBuilder.java:148)
at org.apache.batik.bridge.GVTBuilder.build(GVTBuilder.java:79)
at LoadTester$Runner.buildGVT(LoadTester.java:101)
at LoadTester$Runner.run(LoadTester.java:85)
On 2002.02.20 23:47 Vincent Hardy wrote:
> Keiron,
>
> I see the problem for which you have a fix (DOMException) running your
> test, but I am unable to reproduce the NullPointerException.
>
> Would you have a complete trace of that Exception?
>
> Thanks,
> Vincent.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Vincent Hardy <vi...@sun.com>.
Keiron,
I see the problem for which you have a fix (DOMException) running your
test, but I am unable to reproduce the NullPointerException.
Would you have a complete trace of that Exception?
Thanks,
Vincent.
Keiron Liddle wrote:
>
> Hi Vincent,
>
> The memory thing is better thanks. It appears there can still be some
> threading thing but it is very rare (after about 12000 documents in heavy
> use).
> java.lang.NullPointerException
> at org.apache.batik.bridge.SVGFontUtilities.getFontFamily(Unknown
> Source)
>
> Using the testing that I sent in this email:
> http://marc.theaimsgroup.com/?l=batik-dev&m=100860672129140&w=2
> Is the way the code works valid?
>
> The problem that I encountered there (the style parsing error) I was able
> to solve by putting a static synchronization around the lines 402 - 404 in
> CSSOMStyleDeclaration.
>
> Thanks,
> Keiron.
>
> On 2002.02.20 22:49 Vincent Hardy wrote:
> > Keiron,
> >
> > There is a fix in the CVS repository.
> > Cheers,
> > V.
> >
> > Keiron Liddle wrote:
> > >
> > > Hi,
> > >
> > > I have a couple of problems with the SVGFontUtilities class.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Keiron Liddle <ke...@aftexsw.com>.
Hi Vincent,
The memory thing is better thanks. It appears there can still be some
threading thing but it is very rare (after about 12000 documents in heavy
use).
java.lang.NullPointerException
at org.apache.batik.bridge.SVGFontUtilities.getFontFamily(Unknown
Source)
Using the testing that I sent in this email:
http://marc.theaimsgroup.com/?l=batik-dev&m=100860672129140&w=2
Is the way the code works valid?
The problem that I encountered there (the style parsing error) I was able
to solve by putting a static synchronization around the lines 402 - 404 in
CSSOMStyleDeclaration.
Thanks,
Keiron.
On 2002.02.20 22:49 Vincent Hardy wrote:
> Keiron,
>
> There is a fix in the CVS repository.
> Cheers,
> V.
>
> Keiron Liddle wrote:
> >
> > Hi,
> >
> > I have a couple of problems with the SVGFontUtilities class.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: static/threading problem with SVGFontUtilities
Posted by Vincent Hardy <vi...@sun.com>.
Keiron,
There is a fix in the CVS repository.
Cheers,
V.
Keiron Liddle wrote:
>
> Hi,
>
> I have a couple of problems with the SVGFontUtilities class.
>
> ....
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org