[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-user
Subject:    Re: No default font defined by OutputConverter
From:       "Andreas L. Delmelle" <andreas.delmelle () telenet ! be>
Date:       2011-07-23 20:21:34
Message-ID: 433BDEF2-3ED2-424B-A5BE-12E9281F8C69 () telenet ! be
[Download RAW message or body]

On 22 Jul 2011, at 16:59, Lance Goforth wrote:

Hi Lance

> > <snip />
> > Does the context allow for multiple concurrent sessions, or can the user only \
> > render a single document at a time? Has it been reported across a number of \
> > different Java Runtime implementations or are all users working with the exact \
> > same OS/VM? 
> It should only be allowing one document rendering at one time.  However, I might \
> have to backtrack through the code to verify that is true. 
> All the JVMs should be 1.6, although some minor releases might vary, 1.6.17 and \
> 1.6.22 - all are on a remote windows session running Windows Server 2003

Given that:
a) it has only been noticed with AWT rendering, which relies on the implementation of \
java.awt.font, and b) it runs in remote sessions, which in all likelihood _do_ run \
concurrently --albeit in separate JVM instances  
I am beginning to suspect it is a matter of contention on the OS level. All those JVM \
instances are basically relying on the OS to provide them with the font information. \
If the OS screws that up somehow, then the Java implementation can be as \
good/waterproof as it wants... On the other hand, it may just as well point to a \
quirk in the Java VM implementation, as a lot of those concurrent sessions would \
basically be relying on the same, single Java installation on the server. From that \
perspective, purists could point out that that is simply not how Java was intended to \
be used in the first place. Think of it this way: it is analogous/similar to having \
Windows running in a VM on the server, and booting that VM from scratch for each \
request to render a single document with FOP. All very creative, but that is \
definitely not how virtualization was meant to be used.  Another point of comparison: \
one could conceivably write a client app that, instead of issuing a query via \
standard JDBC, opens a remote desktop session to a server to start up a database \
instance and then issue the query there. Make sense? I didn't think so...

At any rate, if it really is an issue affecting only concurrent runs in separate, \
isolated Java processes, then it is guaranteed that nothing FOP can do, is ever going \
to mitigate that. We can only try to safeguard the code for multiple concurrent runs \
in the same Java runtime. Any synchronization outside of that scope is up to Java \
itself and/or the OS. From FOP's point of view, there are just many isolated \
FopFactory instances that know absolutely nothing about each other, let alone share \
any common info.

An interesting, yet not so straightforward experiment, would be to try this on a \
*nix-ish server, and see whether the issue persists there in a similar context. Java \
is Java, so will run on any Linux variant just as well. If Linux would do a better \
job at keeping those sessions truly separated, the problem would be Windows. If the \
issue persists on Linux as well, it would be a Java issue.

From the looks of it, short-term relief can probably only be obtained, without too \
much effort, by reducing the maximum number of concurrent sessions on the server. \
That would mean that users will have to wait longer. Still, they might find that more \
palatable than the recovery process you referred to.  Other than that, of course you \
could also buy more servers to handle the increased workload... JK ;-)

If you ask me, the better/more robust solution in the longer term would probably mean \
investing in refactoring, in a paradigm shift in the application. Instead of \
previewing in Java AWT in a remote desktop session, just render in PDF, PNG, TIFF... \
and serve that via HTTP as the 'preview'. If the user accepts the preview, the server \
can then optionally write the stream also to a shared location, from where it is \
available for future reference. Or even something more personal, like send a mail \
with the output file as an attachment.


Regards

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


[prev in list] [next in list] [prev in thread] [next in thread]