Hasan,
I've recently fixed a multi-threading problem in the Java2D renderer
which is also responsible for creating TIFF images:
http://svn.apache.org/viewvc?rev=895012&view=rev
Please check if FOP Trunk works for you. Good luck!
On 12.02.2010 19:13:31 HasanK wrote:
>
> Hi,
> We are using Apache FOP 0.95 to produce TIFF images in CCITT T.6 format in a
> j2ee application(thus this is a multithreaded environment). We also use FOP
> 0.95 to produce pdf images in the same application with the same inputs. A
> while back we had an issue where producing the tiff images resulted in
> extreme overlapping in the images(In some cases the application produced
> blank images). Upon initial observation it was observed that the
> transformation that results in the tiff images is not thread safe, while the
> one producing the pdf images is. To test this hypothesis, we have produced
> the test case named Test_FopTiffTransformMultithreaded.java(attached). This
> test case provides proof of concept that the tiff image conversion is not
> thread safe. A few notes on the test case:
> 1) The following jars would be needed in the class path:
> -commons-io-1.3.1.jar
> -fop-0.95.jar
> -xml-apis-ext-1.3.04.jar
> -xmlgraphics-commons-1.3.1.jar
> -spring-2.0.5.jar
> -junit-3.8.1.jar
> -jdom.jar
> -saxpath.jar
> -commons-logging-1.04.jar
> -avalon-framework-4.2.0.jar
> 2) The properties(static strings) in the test case translate as follows:
> EXPECTED_THREAD_COUNT -> the expected number of threads we want to test
> with(value 1 to N)
> OUTPUT_FILE_DIRECTORY_PATH -> The file path to the directory where the
> images are stored
> OUTPUT_FILE_NAME -> The name of the file that will be output(for example if
> this value is "image", and the thread count is 2, then the output files will
> be named as "image0", "image1")
> OUTPUT_FILE_FORMAT -> this value is expected to be either ".pdf" or ".tiff"
> OUTPUT_FILE_FORMAT_TYPE -> this value is expected to be either "pdf" or
> "tiff" and must match the file format in the OUTPUT_FILE_FORMAT above
> PRINTABLE_FO_PATH -> the file path to the xsl transformation file
> 3) The xml file which will be rendered(named "InputFile.xml") in this test
> case should be placed in the same directory as the test case.
> 4) Line 181 of this test case shows the following:
> // synchronized (fopFactory)
> // {
> transformer.transform(src, result);
> // }
> This indicates a synchronization of the fopFactory object. If this
> synchronization block is not present and the output is in tiff images, the
> text in the images is overlapped. If this synchronization block is present,
> there are SEVERE performance implications on our application as this
> synchronization introduces performance issues(I can provide the performance
> differential if needed). An example of the correct image(imageCorrect.tiff)
> is attached and the overlapped image as a result of the multithreaded
> process(EXPECTED_THREAD_COUNT >1) without
> synchronization(imageIncorrect.tiff) is also attached.
>
> I am attaching all the files(except the jars) that are needed for this test
> case.
>
> The following is my question. How can this tiff image problem be corrected?
> As we are working with highly demanding customers(as everyone is :-):-)
> http://old.nabble.com/file/p27567366/Test_FopTiffTransformMultithreaded.java
> Test_FopTiffTransformMultithreaded.java
> http://old.nabble.com/file/p27567366/InputFile.xml InputFile.xml
> http://old.nabble.com/file/p27567366/Transformer.xsl Transformer.xsl
> http://old.nabble.com/file/p27567366/imageCorrect.tiff imageCorrect.tiff
> http://old.nabble.com/file/p27567366/imageIncorrect.tiff imageIncorrect.tiff
> ), we need to solve the performance problems as well as the tiff image
> issue. We would be really grateful if this issue can be solved.
> Thanks
> Hasan
> --
> View this message in context:
> http://old.nabble.com/Tiff-Image-conversion-in-a-multithreaded-environment-tp27567366p27567366.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
