Like Reto, EJBs have been chosen to be strategic technology in my company.
Having tested Fop in Servlets I designed (generating pdf an opening it in
the client's browser) causes no problem ;
in this case, the renderer I use is the PDF one.
But when I want to print directly (using the printer configured on the unix
box), I render the output through a class which extends AWTRenderer
which, and as Reto said, is not thread safe, because of the classe it uses.
So I was able to reproduce the issues outside EJBs.
I will try to write a testCase that reproduces the problems too.
Thanks.
Frédéric
-Message d'origine-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Date: lundi 10 février 2003 16:16
À: [EMAIL PROTECTED]
Objet: Antwort: Re: Antwort: Fop and multithreading.
Hi Jeremias,
I do agree very much with you about the concerns on EJB usage, though
unfortunately drop the EJB idea is not an option.
EJB is the chosen environment in this company (my client). Since XSL:FO has
also been chosen as strategic technology, we are bound to find a way for
the two to coexist. Having a special service for the rendering may be an
option, but in the end this comes down to the same issues than doing it
inside the EJB using seperate ThreadPools, JMS and the like, this is a
long-discussed topic in EJB lists...
It seems obvious that you have not noticed the problems we see, because the
issue is most probably in AWTRenderer and its use of AWT classes
(java.awt.Font, java.awt.FontMetrics, java.awt.graphics).
Your suggestion is a good way forward: I will try write a TestCase that
reproduces the problems outside EJB and we see how we can go on from there.
Is the testcase you used in november available as a starter?
merci,
Reto
___
CSS Versicherung
Reto Blunschi EXTERNE
Rösslimattstrasse 40
CH-6002 Luzern
Telefon ++41 (0)41 369 1236
Telefax ++41 (0)41 369 1212
[EMAIL PROTECTED]
www.css.ch
Jeremias Maerki [EMAIL PROTECTED] on 10.02.2003 14:08:11
Bitte antworten an [EMAIL PROTECTED]
An: [EMAIL PROTECTED]
Kopie:
Thema: Re: Antwort: Fop and multithreading.
Frédéric and Reto,
having read the 24.1.2 Programming restrictions of the EJB 2.0
specification, I'd recommend you guys don't call FOP from an EJB. The
programming restrictions forbid among other things the following:
- Reading or writing of static variables (FOP still does this too often)
- Use of thread synchronization primitives (FOP does that mostly because
of the static variables)
- Use of AWT functionality
- Use of java.io package to access files (which obviously happens as
well)
So the singleton may also be a bad idea. I recommend you don't use FOP
within EJBs. Use a Servlet, a WebService or a custom-built server
service instead.
I've done some serious debugging of multithreading issues last November
by writing a test application that uses FOP in a multi-threaded fashion
(PDF only, no AWT). I haven't had the symptoms you describe so I can
only imagine it has to do with the enviroment (EJBs). Of course, it
could be that my test application was suboptimal, so maybe you two can
come up with a test application that triggers your symptoms outside an
EJB server. That would help track the error down. If you can't reproduce
the bug outside the EJB server I recommend you drop the EJB idea.
You can find the spec mentioned above here:
http://java.sun.com/products/ejb/docs.html#specs
Good luck!
On 10.02.2003 13:00:56 frederic.kieffer wrote:
Thanks for your help.
In addition, I'm in the same kind of situation as you are (multiprocessor
Unix box, executing FOP in a Message Driven EJB on JBoss).
I designed a singleton class which is used by this ejb each time a
message
is being consumed.
I'm going to try to synchronize its methods. Maybe this will help.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
