Re: Multithreading FOP ?

2002-04-11 Thread Chaumette, Patrick

Hello,

could you precise the degree of threadsafeness ?
I read about the problems with the image package, are there other areas ?

The possible use of FOP in WebSphere without any servlet is currently my
interest.
Sure, one could use some pessimistic concurrency implementation like monitor
objects and other locks.

Do people using FOP in a servlet environment have problems beside image
stuff ?

Thanks,
greetings,
Patrick

--
Dipl. Inform. Patrick Chaumette

T-Systems ITS GmbH

Service Prozesse Retail
Hausanschrift: Fasanenweg 9, 70771 Leinfelden-Echterdingen
Postanschrift: Postfach 100258, 70746 Leinfelden-Echterdingen
Telefon: (0711)972-2437
Telefax: (0711)972-1949
E-Mail: [EMAIL PROTECTED]
Internet: http://www.t-systems.de



-Ursprüngliche Nachricht-
Von: Jeremias Maerki [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 11. April 2002 13:16
An: [EMAIL PROTECTED]
Betreff: Re: Multithreading FOP ?


To a certain degree, yes. Not all issues have been dealt with, yet.

 I read in an older posting that FOP is not thread safe.
 Is this still the case ?

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Multithreading FOP ?

2002-04-11 Thread Jeremias Maerki

 could you precise the degree of threadsafeness ?
 I read about the problems with the image package, are there other areas ?

I think that's the worst bug right now. There is another one, but I
can't find it anymore.

 The possible use of FOP in WebSphere without any servlet is currently my
 interest.
 Sure, one could use some pessimistic concurrency implementation like monitor
 objects and other locks.
 
 Do people using FOP in a servlet environment have problems beside image
 stuff ?
I'm not using it in a servlet environment but I restricted our server to
process only one document at once because of these problems.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




RE: Multithreading

2001-07-17 Thread Jim Cotugno

 I don't know if anyone has done any extensive testing of concurrency with
 FOP, so please let us know what problems you run into (the IndexOutOfBounds
 for example), either via this list, or better yet, via Bugzilla so we can
 track and fix the issues. I've fixed a few places where I found concurrency
 issues at one time, but I'm sure there are others I didn't find.

When we attempted to use FOP in a multi-processor, multi-threaded 
Windows NT 4.0 environment, we found that FOP actually worked 
SLOWER than a single processor and/or single-threaded 
environment.  We ran multiple threads that were responsible for 
rendering separate documents.  We were trying to reduce the 
elapsed time necessary to render thousands of relatively small (10-
20 page) documents.

What we found was running multiple FOP threads on a multi-
processor Windows NT box reduced our total throughput.  We 
processed more documents per hour with a single FOP thread than 
we did with multiple FOP threads.  Note that I'm refering to total 
throughput, not documents per thread per hour.

Some analysis pointed to VERY HIGH context switching going on 
when running two FOP threads on a two processor system.  What 
this told us was that the two FOP threads were fighting over the 
same piece(s) of memory continuously.  This context switching went 
away when we ran multiple FOP threads on a single processor 
machine or we ran a single FOP thread on a multi-processor 
machine.  

I spent some time looking at the source code, and noticed a large 
number of statics being declared all throughout FOP.  This may be a 
cause, or it may have something to do in the way the Sun jvm works 
on Windows.  I didn't have the time to dig deeper.  

I don't remember the exact version of FOP we used for the test.  It 
may have been 0.18.1 or 0.19.0-CVS.  

Jim Cotugno
Upstanding
email:  [EMAIL PROTECTED]
home email: [EMAIL PROTECTED]
phone:  949-453-2000
fax:949-453-2001

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




RE: Multithreading

2001-07-17 Thread Jim Urban

We are planning to use FOP in our web application.  The application will be
hosted on a W2K box with dual PIIIs.  We will use FOP in servlets to allow
the user to dynamically generate formatted reports (in PDF) that can be
printed off and inserted in a patients permanent medical file.  Does this
mean we can expect performance problems from our print servlets?

Jim Urban
Product Manager
Netsteps Inc.
Suite 505E
1 Pierce Pl.
Itasca, IL  60143
Voice:  (630) 250-3045 x2164
Fax:  (630) 250-3046


-Original Message-
From: Jim Cotugno [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 17, 2001 1:10 PM
To: [EMAIL PROTECTED]
Subject: RE: Multithreading


 I don't know if anyone has done any extensive testing of concurrency with
 FOP, so please let us know what problems you run into (the
IndexOutOfBounds
 for example), either via this list, or better yet, via Bugzilla so we can
 track and fix the issues. I've fixed a few places where I found
concurrency
 issues at one time, but I'm sure there are others I didn't find.

When we attempted to use FOP in a multi-processor, multi-threaded
Windows NT 4.0 environment, we found that FOP actually worked
SLOWER than a single processor and/or single-threaded
environment.  We ran multiple threads that were responsible for
rendering separate documents.  We were trying to reduce the
elapsed time necessary to render thousands of relatively small (10-
20 page) documents.

What we found was running multiple FOP threads on a multi-
processor Windows NT box reduced our total throughput.  We
processed more documents per hour with a single FOP thread than
we did with multiple FOP threads.  Note that I'm refering to total
throughput, not documents per thread per hour.

Some analysis pointed to VERY HIGH context switching going on
when running two FOP threads on a two processor system.  What
this told us was that the two FOP threads were fighting over the
same piece(s) of memory continuously.  This context switching went
away when we ran multiple FOP threads on a single processor
machine or we ran a single FOP thread on a multi-processor
machine.

I spent some time looking at the source code, and noticed a large
number of statics being declared all throughout FOP.  This may be a
cause, or it may have something to do in the way the Sun jvm works
on Windows.  I didn't have the time to dig deeper.

I don't remember the exact version of FOP we used for the test.  It
may have been 0.18.1 or 0.19.0-CVS.

Jim Cotugno
Upstanding
email:  [EMAIL PROTECTED]
home email: [EMAIL PROTECTED]
phone:  949-453-2000
fax:949-453-2001

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




RE: Multithreading

2001-07-17 Thread Jess Holle and Wendy Vidlak

In the interim (i.e. until code improvements), did you try multiple
*processes* rather than threads, i.e. to ensure multiple copies of statics,
etc, so contention within a process is eliminated?

It may well still be that other forms of contention limit the throughput

-Original Message-
From: Jim Cotugno [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 17, 2001 1:10 PM
To: [EMAIL PROTECTED]
Subject: RE: Multithreading


 I don't know if anyone has done any extensive testing of concurrency with
 FOP, so please let us know what problems you run into (the
IndexOutOfBounds
 for example), either via this list, or better yet, via Bugzilla so we can
 track and fix the issues. I've fixed a few places where I found
concurrency
 issues at one time, but I'm sure there are others I didn't find.

When we attempted to use FOP in a multi-processor, multi-threaded
Windows NT 4.0 environment, we found that FOP actually worked
SLOWER than a single processor and/or single-threaded
environment.  We ran multiple threads that were responsible for
rendering separate documents.  We were trying to reduce the
elapsed time necessary to render thousands of relatively small (10-
20 page) documents.

What we found was running multiple FOP threads on a multi-
processor Windows NT box reduced our total throughput.  We
processed more documents per hour with a single FOP thread than
we did with multiple FOP threads.  Note that I'm refering to total
throughput, not documents per thread per hour.

Some analysis pointed to VERY HIGH context switching going on
when running two FOP threads on a two processor system.  What
this told us was that the two FOP threads were fighting over the
same piece(s) of memory continuously.  This context switching went
away when we ran multiple FOP threads on a single processor
machine or we ran a single FOP thread on a multi-processor
machine.

I spent some time looking at the source code, and noticed a large
number of statics being declared all throughout FOP.  This may be a
cause, or it may have something to do in the way the Sun jvm works
on Windows.  I didn't have the time to dig deeper.

I don't remember the exact version of FOP we used for the test.  It
may have been 0.18.1 or 0.19.0-CVS.

Jim Cotugno
Upstanding
email:  [EMAIL PROTECTED]
home email: [EMAIL PROTECTED]
phone:  949-453-2000
fax:949-453-2001

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




Re: Multithreading problems

2001-06-13 Thread Jeremias Maerki

Kelly and Arved, thank you your comments. 

 At 01:56 PM 6/12/01 -0600, Kelly Campbell wrote:
 I seem to remember fixing some of the possible problems in a more recent
 release. And I know Keiron or Arved also fixed a problem with a static page
 numbering variable that would cause problems like that.
 
 To be exact, the fact that page-number was static was changed, precisely 
 because it _was_ a problem in multi-threading. This broke page-numbering 
 state across page-sequences, and still remains to be handled (obvious way is 
 to pull logic up into Root).

That was probably runningePagNumberCounter. I'll see if this is enough.

 Try 0.18.1 and see if it works better for your application.

Big adventure to try to recreate my changes there.

 One approach for tracking down strange problems when running multiple
 threads is to look for any non-final static class variables. These are
 likely candidates for problems like that.

So I found a few candidates:
- Configuration stuff (unlikely to cause problems, but inhibits using
  different configurations at the same time, right? Maybe it's time to
  have another look at Avalon.)
- MessageHandler stuff (similar to above)
- FopImageFactory m_urlMap (Maybe. I've had some error message with
  images but that could be my special URL type)
- ImageReader formats (no real candidate, but the variable should be
  filled in a static block, not in the constructor)


Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]