I'm having problems using iText in a multi-threaded environment.
I built a small test app to see how iText would perform when
used on a machine with multiple cpu's, and the results were
not what I expected.
The test code is fairly simple; I built a class that extends
Thread:
class mythread extends Thread
{
}
and within that class's run method, I do some simple iText
things, like:
create a PdfReader.
create a PdfStamper.
loop thru all pages of the input document, stamping
some text on each page.
close the Stamper.
close the Reader.
output a line to the console reporting the total elapsed time
since the run() method was entered.
The main code of this test application handles the details of
creating a fixed number of instances of the 'mythread' object,
(the actual number is hardcoded in the module), and reads a simple
text file that drives the process (the text file contains one
line for each pdf file to be created).
I've been careful to ensure that none of the threads attempt to
use the same input file, or create the same output file.
The text file contains 10 lines of input, meaning 10 pdf files
will be created.
I'm running the test on a machine with 2 quad-core Intel processors,
for a total of 8 cpu's.
Here's the interesting (and not so thrilling) part: as I increase
the number of threads that will be used to process files (and therefore
increase the number of cpu's that will be used), the time required for
each thread to complete increases significantly.
here are some approximate values of thread count vs. elapsed run
time per thread:
threads - elapsed time (in ms) per thread
1 - 800
2 - 1600
4 - 4500
8 - 10000
This seemed very strange to me, and I immediately assumed the problem
was that I was doing something wrong regarding my use of threads.
With that in mind, I replaced the 'mythread' class and all it's iText
calls with something that was iText-free, but still opened files and
gobbled up a bunch of cpu time.
This time I got what I was expecting: as more threads/cpus were
allocated
to the job, the amount of work accomplished increased accordingly -
and not
just a little. And this time, the amount of elapsed time taken for each
thread to complete remained consistent, regardless of the total number
of threads being executed.
Believing now that my thread handling was not the problem, I put the
iText
code back in place, and started looking at where the delays were
occurring.
I soon discovered that the delays were happening in the Stamper.close()
function, in PdfStamperImp.java.
I grabbed the iText source, added some print statements in various
places
throughout the Stamper.close() function, and determined that the code
causing the delays is within this loop (in the close() method in
PdfStamperImp.java):
for (int k = 1; k < reader.getXrefSize(); ++k) {
PdfObject obj = reader.getPdfObjectRelease(k);
if (obj != null && skip != k) {
addToBody(obj, getNewObjectNumber(reader, k, 0), k != rootN);
}
At this point I thought it would make more sense to post my problem here
and hope that someone can offer some explanation as to why processing
slows down drastically as more threads are used.
Thanks in advance for any assistance.
Robert Meyer.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.1t3xt.com/docs/book.php
