Best pratrice for OfficeManager & OfficeDocumentConverter in a multithreaded environment

[Jeremy Chone]

Hi,

 

So, I get my first conversion working from a Web Application, with the simple code:

 

        OfficeManager officeManager = new ManagedProcessOfficeManager();

        officeManager.start();

 

        OfficeDocumentConverter converter = new OfficeDocumentConverter(officeManager);

        converter.convert(source, dest);

 

        officeManager.stop();

 

 

Now, in a multithreaded environment (i.e. Servlet/Request), what can be reused across threads?

 

1)      Can I keep the same OfficeManager for all my threads?

 

2)      Could I create a different Converter per thread?

 

I assume and hope that the answer to #1 and #2, is yes and yes, but just want to double check.

 

Thank you,

 

 

 

Jeremy Chone

+1 415 699 9912

www.jeremychone.com

 

[Mirko Nasato]

Hi Jeremy,

Yes the OfficeManager instance can and should be shared across all
threads. It should typically be started when your webapp starts, and
stopped when the webapp stops. It can be e.g. a singleton, or a Spring
bean, or other equivalent approach of your choice.

The OfficeDocumentConverter instance can also be shared, or you can
create a different instance per thread. It doesn't really matter,
since all conversions will be delegated to the OfficeManager anyway.

(There's also a sample webapp in the repository - although being based
on the latest trunk the code differs slightly from beta-1.)

Cheers

Mirko


2009/4/10 Jeremy Chone <jeremy...@gmail.com>:

[Jeremy Chone]

Great, perfect. Tx.

Jeremy Chone
+1 415 699 9912
www.jeremychone.com

[Jeremy Chone]

BTW, JodConverter is working like a charm on Linux as well. I just had to
make sure it was installed (or references) from /opt/openoffice.org3 (I had
it in a different location, but when I did the symbolic link, it was fine)

Jeremy Chone
+1 415 699 9912
www.jeremychone.com

-----Original Message-----
From: jodcon...@googlegroups.com [mailto:jodcon...@googlegroups.com]
On Behalf Of Mirko Nasato
Sent: Friday, April 10, 2009 10:55 AM
To: jodcon...@googlegroups.com
Subject: Re: Best pratrice for OfficeManager & OfficeDocumentConverter in a
multithreaded environment

[Mirko Nasato]

Yes it expects OOo in /opt/openoffice.org3 by default, but you can
pass a different officeHome to the OfficeManager constructor, or set a
-Doffice.home=... Java system property.

Cheers

2009/4/10 Jeremy Chone <jeremy...@gmail.com>:

[Laurent Bois]

Hi,

I also put JODConverter in a Grails web app. I put the OfficeManager
in a Groovy service, started in the Booting script.

My question is now how does OpenOffice support well concurrent
conversion via TCP mode?
Actually, from my web controller , i push a Job request in a simple
Blocking Queue (i'm in the mode producer-consumer)
The consumer is a Thread, that takes posted entries from the queue
(and blocks when there's nothing to dequeue).
I have the choice to do the conversions :
- as a sequential manner : the consumer threads dequeues, starts the
conversion tasks, and waits for entries again when conversion finished
- as asynchronous manner : the consumer threads dequeues, launch the
conversion task as a thread, and waits for entries immedialtely.
In solution 2 (async) i want to limit nb of thread in a ThreadPool.
Despite i have a preference for sol. 2 , i wonder how OpenOffice
supports concurrent access for conversions
Everything works fine on a Mac with Groovy and OOo 3 : OOo 3 is just
launched with its GUI (no headless mode) but it's just a development
platform. Finally i'll run it on Ubuntu 8.10 ;-) or Windows
(preference for Linux).
Thanks
Laurent

[Mirko Nasato]

Hi Laurent,

OOo doesn't handle multi-threading very well, as shown in this page

http://wiki.services.openoffice.org/wiki/Effort/Revise_OOo_Multi-Threading

For this reason JODConverter already takes care of passing conversions
to OOo in a sequential manner. This is done by the OfficeManager
implementation. So you don't need to re-implement a similar
functionality in your own application.

Cheers

Mirko

2009/4/27 Laurent Bois <lauren...@gmail.com>:

[Laurent Bois]

Hi Mirko

Thanks for the reply.

In fact, the Queu i did was not initially for OOo itself :

In my web app, i want to offer the possibility to upload several files in a form... then i submit the Job (to a queue) in async mode..

The user is redirected fastly to a download page (where you can see : Working in progress for example, then a link for each processed file once finished, or a link for the zip that contains all the processed files)

I just wanted to know for the Thread that dequeues (the Queue accepting jobs requests from my Grails controller) : 

1) If it launches conversion sequentially ( before listening again to the tail of the queue)

2) or if it launches the conversion asynchronously  , with an executor.

In case 2, that's right it sounds like ridiculous because

request --> Job request Queue -> Dequeue (thread) -> Process conversion task (Thread) -> and finally officeManager that manages the conversion tasks in OOo as a sequential manner.

So perhaps case 1 could be sufficient.

Laurent

2009/4/27 Mirko Nasato <mirko....@gmail.com>

--

Laurent Bois
--
HADOPI - Le Net en France : black-out
Skype : laurentbois
http://talk.to/lbois
http://www.laurentbois.com/