A simpler way to serialize multiple requests

[hagen00]

Hi there,

I'm using OO macros on Linux which i call through php accessing a shell script to convert ppt to jpg and also calc to excel and maybe pdf etc.

After doing some testing i found that OO doesn't like processing more than one thing at the time - ie if i called, for example, the shell script to convert ppt to jpg twice with about a second interval, then it would only process the first shell script request and not the second. Through further research i found that this is a problem with OO and also found a couple of solutions eg:

- using this daemon to queue requests to OO: http://udk.openoffice.org/python/oood/

- have multiple soffice's running which requires installing OO multiple times for one user

None of the solutions seemed to be simple. Granted, i've only been researching this for a couple of hours, but in my situation where i don't do mass conversions there shouldn't be that many instances where OO is being requested concurrently.

So here's what i want to try:

1. In my shell script i test to see if soffice is running through ps -e | grep soffice...(or something like that)
2. If it is running, sleep 2 (wait two seconds)
3. Test again until not running anymore.
4. If not running anymore, launch soffice and execute macro.

Note: For each conversion, i open up OO and when it's done i close it again.

Now this seems much simpler to me and it should queue the scripts nicely by making them wait until OO is not running anymore before starting it up again. It will come short if two requests are made at exactly the same time, but that's pretty unlikely i think.

So i'm going to go ahead and try this. I just thought i'd post to get some feedback. This seems too simple, am i missing something obvious?

I'd love to hear some thoughts.

Kind Regards

Hagen

[hol.sten]

[hagen00]

Just to post an update....

I've tried my plan with 3 users converting concurrenlty. (Obviously not completely concurrently, but we tried to click "Convert" at exactly the same time)

It works fine when i set the delay to 2 seconds.

To continue the queue analogy that Danny used in a post somewhere, in this way of managing concurrent use, users do not form an orderly line like they would at a bank ie the last person joins at the back. It is basically a free for all - more like a bus stop - with everyone trying to get to the front. Only one person at a time can enter the bus, but the person entering is not necessarily the one waiting the longest. Maybe not ideal, but fine for me, since the conversion processes run in the background and users don't have to wait for them to finish before they can continue.

If anyone needs the shell code for this, ask and i'll post it, but it is fairly straight forward.

cheers

Hagen

[stefan_b]

I too have conducted a short and not very scientific experiment on this subject. It goes like this

1. Have a Java client programme spawn 5 threads, each opening a different document (4 text, 1 presentation). There is no delay between opening individual documents, it happens as fast as the machine can handle.

2. Have each thread automate the relevant application to extract the text content from the open file and write it out to a plain text file.

3. Wait in a loop whilst the threads execute.

4. When all threads have completed close source files and text files and exit programme.

All this works without errors and takes about 12.5 seconds to run to completion. This would seem to contradict earlier posts regarding concurrent requests and the OOo process crashing.

Interestingly, the threads seem to complete in reverse order to that in which they were started, though this could be more to do with my programme and document lengths than anything else.

Stefan

[hol.sten]