RE: Possible thread-safe issue with fonts

2002-04-29 Thread Chris Warr

It'll do, I just load tested it overnight, no problems for 250,000 hits.
I'm running through cocoon, I don't want to be playing with cocoon's source
as well.

Chris.

-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 30 April 2002 6:44
To: [EMAIL PROTECTED]
Subject: Re: Possible thread-safe issue with fonts


Chris Warr wrote:
> OK, it was a threading issue, I downloaded the source and had a play.  It
> comes about because the static configuration is updated for every
> translation I do.  FontSetup.addConfiguredFonts() can read from the font
> list at the same time as ConfigurationParser.store() updates it.  I just
put
> a line in ConfigurationParser.endElement() to only add fonts if there are
> none in the list.  Was easier for me than mucking around with
> 'synchronized', I'm only a java beginner.
> 
> 
> } else if (localName.equals("fonts")) {
> -->if (Configuration.getFonts() != null &&
> Configuration.getFonts().size() != 0)
> -->{
> -->// Don't update the fonts
> -->}
> -->else
>{
>this.store("standard", "fonts", fontList);
>}

That's not a good idea.
If you have only one servlet and set the configuration
only once, do so in the servlet's init() method.
If you have several servlets, create a singleton class
wrapping the instantiation of the configuration,
roughly
  final class ConfigSingleton {
   private static Options options;
   public final void synchronized init() {
 if( options==null ) {
   options=new Options("userconfig.xml");
 }
   }

(Beware! Untested!)
And call ConfigSingleton.init() in each of the servlet's
init method.

J.Pietschmann



Re: Possible thread-safe issue with fonts

2002-04-29 Thread J.Pietschmann
Chris Warr wrote:
OK, it was a threading issue, I downloaded the source and had a play.  It
comes about because the static configuration is updated for every
translation I do.  FontSetup.addConfiguredFonts() can read from the font
list at the same time as ConfigurationParser.store() updates it.  I just put
a line in ConfigurationParser.endElement() to only add fonts if there are
none in the list.  Was easier for me than mucking around with
'synchronized', I'm only a java beginner.
} else if (localName.equals("fonts")) {
-->if (Configuration.getFonts() != null &&
Configuration.getFonts().size() != 0)
-->{
-->// Don't update the fonts
-->}
-->else
   {
   this.store("standard", "fonts", fontList);
   }
That's not a good idea.
If you have only one servlet and set the configuration
only once, do so in the servlet's init() method.
If you have several servlets, create a singleton class
wrapping the instantiation of the configuration,
roughly
 final class ConfigSingleton {
  private static Options options;
  public final void synchronized init() {
if( options==null ) {
  options=new Options("userconfig.xml");
}
  }
(Beware! Untested!)
And call ConfigSingleton.init() in each of the servlet's
init method.
J.Pietschmann



RE: Possible thread-safe issue with fonts

2002-04-29 Thread Chris Warr

OK, it was a threading issue, I downloaded the source and had a play.  It
comes about because the static configuration is updated for every
translation I do.  FontSetup.addConfiguredFonts() can read from the font
list at the same time as ConfigurationParser.store() updates it.  I just put
a line in ConfigurationParser.endElement() to only add fonts if there are
none in the list.  Was easier for me than mucking around with
'synchronized', I'm only a java beginner.


} else if (localName.equals("fonts")) {
-->if (Configuration.getFonts() != null &&
Configuration.getFonts().size() != 0)
-->{
-->// Don't update the fonts
-->}
-->else
   {
   this.store("standard", "fonts", fontList);
   }

-Original Message-
From: Chris Warr [mailto:[EMAIL PROTECTED]
Sent: Monday, 29 April 2002 9:07
To: [EMAIL PROTECTED]
Subject: RE: Possible thread-safe issue with fonts


I don't get that error, just the one 'unknown font dynamo...'

Is this more appropriate for fop-dev?

Chris.

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]
Sent: Friday, 26 April 2002 17:26
To: [EMAIL PROTECTED]
Subject: Re: Possible thread-safe issue with fonts



It sounds like it is a threading problem.

Do you get any messages like:
"Failed to read font metrics file ... "

It would appear that two threads could be reading the font metrics file at 
the same time.
Accessing the file is done through the parser so we don't know what it is 
actually doing and it depends on the parser.
I think each time it is a new data set in memory so it probably is not 
that.



On 2002.04.26 08:17 Chris Warr wrote:
> 
> Hi, I'm running cocoon 2.1dev under tomcat 4.04b2 with JDK 1.3 and FOP
> 0.20.3.  My cocoon app is generating a PDF using FOP.  I use and embed a
> font in my generated PDF file with the following in my userconfig file:
> 
>kerning="yes"
> embed-file="d:/fonts/dynamo.pfb">
>weight="normal"/>
>weight="bold"/>
>   
> 
> This all works fine and dandy under normal usage, I get the dynamo font
> embedded in my PDF and all is well.  However if I run a load test (20
> concurrent processes) on the same app. I get the following error appear
> in
> my tomcat log files:
> 
> 2002-04-26 15:25:20 ERROR   (2002-04-26) 15:25.20:375   [fop ]
> (/cocoon/invoice.pdf) HttpProcessor[80][11]/MessageHandler: unknown font
> dynamo,normal,normal so defaulted font to any
> 
> Not for every hit, but for some.  So I'm guessing that there is some sort
> of
> problem with resource sharing.  That is, could FOP not be thread safe as
> far
> as accessing this file?  Or if the file is loaded into memory once, could
> there be multi-threading issues with reading from wherever it is stored
> in
> memory?
> 
> Anyone got any ideas?
> 
> Chris.
> 


RE: Possible thread-safe issue with fonts

2002-04-28 Thread Chris Warr
I don't get that error, just the one 'unknown font dynamo...'

Is this more appropriate for fop-dev?

Chris.

-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]
Sent: Friday, 26 April 2002 17:26
To: [EMAIL PROTECTED]
Subject: Re: Possible thread-safe issue with fonts



It sounds like it is a threading problem.

Do you get any messages like:
"Failed to read font metrics file ... "

It would appear that two threads could be reading the font metrics file at 
the same time.
Accessing the file is done through the parser so we don't know what it is 
actually doing and it depends on the parser.
I think each time it is a new data set in memory so it probably is not 
that.



On 2002.04.26 08:17 Chris Warr wrote:
> 
> Hi, I'm running cocoon 2.1dev under tomcat 4.04b2 with JDK 1.3 and FOP
> 0.20.3.  My cocoon app is generating a PDF using FOP.  I use and embed a
> font in my generated PDF file with the following in my userconfig file:
> 
>kerning="yes"
> embed-file="d:/fonts/dynamo.pfb">
>weight="normal"/>
>weight="bold"/>
>   
> 
> This all works fine and dandy under normal usage, I get the dynamo font
> embedded in my PDF and all is well.  However if I run a load test (20
> concurrent processes) on the same app. I get the following error appear
> in
> my tomcat log files:
> 
> 2002-04-26 15:25:20 ERROR   (2002-04-26) 15:25.20:375   [fop ]
> (/cocoon/invoice.pdf) HttpProcessor[80][11]/MessageHandler: unknown font
> dynamo,normal,normal so defaulted font to any
> 
> Not for every hit, but for some.  So I'm guessing that there is some sort
> of
> problem with resource sharing.  That is, could FOP not be thread safe as
> far
> as accessing this file?  Or if the file is loaded into memory once, could
> there be multi-threading issues with reading from wherever it is stored
> in
> memory?
> 
> Anyone got any ideas?
> 
> Chris.
> 


Re: Possible thread-safe issue with fonts

2002-04-26 Thread Keiron Liddle
It sounds like it is a threading problem.
Do you get any messages like:
"Failed to read font metrics file ... "
It would appear that two threads could be reading the font metrics file at 
the same time.
Accessing the file is done through the parser so we don't know what it is 
actually doing and it depends on the parser.
I think each time it is a new data set in memory so it probably is not 
that.


On 2002.04.26 08:17 Chris Warr wrote:
Hi, I'm running cocoon 2.1dev under tomcat 4.04b2 with JDK 1.3 and FOP
0.20.3.  My cocoon app is generating a PDF using FOP.  I use and embed a
font in my generated PDF file with the following in my userconfig file:




This all works fine and dandy under normal usage, I get the dynamo font
embedded in my PDF and all is well.  However if I run a load test (20
concurrent processes) on the same app. I get the following error appear
in
my tomcat log files:
2002-04-26 15:25:20 ERROR   (2002-04-26) 15:25.20:375   [fop ]
(/cocoon/invoice.pdf) HttpProcessor[80][11]/MessageHandler: unknown font
dynamo,normal,normal so defaulted font to any
Not for every hit, but for some.  So I'm guessing that there is some sort
of
problem with resource sharing.  That is, could FOP not be thread safe as
far
as accessing this file?  Or if the file is loaded into memory once, could
there be multi-threading issues with reading from wherever it is stored
in
memory?
Anyone got any ideas?
Chris.


Possible thread-safe issue with fonts

2002-04-26 Thread Chris Warr

Hi, I'm running cocoon 2.1dev under tomcat 4.04b2 with JDK 1.3 and FOP
0.20.3.  My cocoon app is generating a PDF using FOP.  I use and embed a
font in my generated PDF file with the following in my userconfig file:






This all works fine and dandy under normal usage, I get the dynamo font
embedded in my PDF and all is well.  However if I run a load test (20
concurrent processes) on the same app. I get the following error appear in
my tomcat log files:

2002-04-26 15:25:20 ERROR   (2002-04-26) 15:25.20:375   [fop ]
(/cocoon/invoice.pdf) HttpProcessor[80][11]/MessageHandler: unknown font
dynamo,normal,normal so defaulted font to any

Not for every hit, but for some.  So I'm guessing that there is some sort of
problem with resource sharing.  That is, could FOP not be thread safe as far
as accessing this file?  Or if the file is loaded into memory once, could
there be multi-threading issues with reading from wherever it is stored in
memory?

Anyone got any ideas?

Chris.