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: [email protected] For additional commands, e-mail: [email protected]
