Hi Daniel,
Sorry, but this is not exactly what I mean.
First of all the main idea of the callback is to call the office API
method from it. Thus the OOoWaitCallback should call
XComponentLoader.loadComponentFromURL() and etc from notify() call. To
reach this, the information about kind of call and about arguments
should be provided in constructor in this case.
Just to explain the mechanics for better understanding. When java
application calls an UNO API method through a bridge, a new thread is
created on Office side and the method is executed in this thread.
When the XRequestCallback.addCallback() is called it sends a
notification with arguments to the main office thread and returns. After
a while the main thread calls XCallback::notify(), and if this method
does a call to the office back, the call is handled in the office main
thread.
Second, I assume that it is not necessary in your implementation to
check the thread name. In the example I have mentioned the thread name
was used to mark the thread that was called from office thread, and thus
needed no workaround. In your case it is not possible I assume, so I
would just remove the check and use the callback workaround always.
As for the listeners, I do not know details of XDocumentIndex.update()
implementation. But at least XComponentLoader.loadComponentFromURL() and
XStorable.storeToURL() should be synchronous, and thus do not really
need any kind of listener usually.
Although there is a problem in case of
XComponent.loadComponentFromURL(). In case a html filter is used to load
a document, the filter does some actions asynchronously. This is already
recognized as a wrong behavior, but I am not sure whether it was
completely fixed.
Hope that helps.
Best regards,
Mikhail.
On 02/24/09 21:55, Daniel Brosseau wrote:
Hi again Mikhail,
This is what I did using the AsyncCallback:
I created a class on the model of the MainThreadDialogExecutor.java you
pointed
me to:
public class OooWaitCallback implements XCallback
{
private boolean m_bCalled = false;
static public boolean WaitOnOoo( XComponentContext xContext )
{
OooWaitCallback aExecutor = new OooWaitCallback();
return GetCallback( xContext, aExecutor );
}
static private boolean GetCallback
( XComponentContext xContext, OooWaitCallback aExecutor )
{
try
{
if ( aExecutor != null )
{
String aThreadName = null;
Thread aCurThread = Thread.currentThread();
if ( aCurThread != null )
aThreadName = aCurThread.getName();
if ( aThreadName != null && aThreadName.equals( "main" ) )
{
// the main thread should be accessed asynchronously
XMultiComponentFactory xFactory = xContext.getServiceManager();
if ( xFactory == null )
throw new com.sun.star.uno.RuntimeException();
XRequestCallback xRequest =
(XRequestCallback)UnoRuntime.queryInterface(
XRequestCallback.class,
xFactory.createInstanceWithContext
( "com.sun.star.awt.AsyncCallback", xContext ) );
if ( xRequest != null )
{
xRequest.addCallback( aExecutor, Any.VOID );
do
{
Thread.yield();
}
while( !aExecutor.m_bCalled );
}
}
else
{
// handle it as a main thread
aExecutor.notify( Any.VOID );
}
}
}
catch( Exception e )
{
e.printStackTrace();
}
return true;
}
public void notify( Object aData )
{
m_bCalled = true;
}
};
Immediately after each call to openOffice.org in my main program such as
xCloseable.close() or xComponentLoader.loadFromUrl() or
xDocumentIndex.update() etc
I make a call to OooWaitCallback.WaitOnOoo().
I have now tested the program several times and where before without the
WaitOnOoo calls
it would consistently hang, it has not hung once.
What I understand is happening is the callback request is being placed in
the job queue
that soffice.bin has been requested to handle. This callback request will be
honored once
soffice.bin has finished its previous business as everything is happening
synchronously.
Until soffice calls the callback, my main thread is yielding.
Does it make sens that as I have implemented it, this would resolve the
problem? Also,
Because everything is happening synchronously, I really should not need any
listeners?
Regards,
Daniel
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: February 24, 2009 4:19 AM
To: [email protected]
Subject: Re: [api-dev] Xstorable.storeToUrl locks soffice.bin
Hi Daniel,
First of all what do you name the main thread?
As I understood you use own java application that connects
the office using UNO API. The main thread of the java
application does not correspond to the main thread of the
office process it connects ( at least it was so before ).
As I have written in one of my previous answers, please try
to use "com.sun.star.awt.AsyncCallback" service to get a
callback from the office main thread. In this case you can
use the callback to do your API call in the office main thread.
The remaining lock file looks in this case like a result of
non-closed model. The model is the object that creates lock
file on document opening and closes it on closing. The office
never waits for a document lock file to continue, except the
case of error/query message shown during document opening/storing.
Anyway, the stack of the deadlock would be very interesting.
Best regards,
Mikhail.
On 02/24/09 07:05, Daniel Brosseau wrote:
Hi,
In everything done in one main thread with no GUI, my program
loadsFromUrl from the Frame a first ODT file and then
appends one or
more ODT files to this through a XTextCursor and
XDocumentInsertable.
After all files are appended I do a XRefreshable.refresh().
I then move to the beginning of the XTextDocument and
insert a Table
of Contents, do another XRefreshable.refresh() and a
XDocumentIndex.update which I retreived through a XServiceInfo.
At this point I can do one of two things:
i) print the document through a XPrintable with a property
"Wait" of
true and
for belts and suspenders a XPrintJobListener and
XPrintJobBroadcaster
(I do not think I need this with "Wait") Or ii)
storeToUrl through
a XStorable using the PDF filter "writer_pdf_Export",
Asynchron of false and Overwrite true.
The program then loops back to the beginning and
loadsFromUrl/Append/etc for another set of files ... (after
the load I
close the released Xmodel, but am I leaking a Controller which I
should also close?)
If all I do is print, the the program can handle several
sets of files
without a problem but if I storeToUrl then soffice.bin will
typically
hang after 1 to 5 stores.
The specific set of loaded files that causes soffice.bin to hang
varies from run to run but inevitably soffice.bin hangs. In the
directory from which the files are loaded, I see Appear a file
.~lock.fileName.ODT# where the fileName is the name of
first file of
the set that was loaded through loadFromUrl which
corresponds to the
XModel's URL property.
Evidently, having soffice.bin hang is a problem. What I
don't know is
if
i) it is a threading issue relating to synchronization of
the store,
the refresh or
the update
Or ii) their is a file lock taken out that soffice.bin is
waiting to
have released before
continuing.
Really what I would like to know is how to avoid the
hanging soffice.bin.
When soffice.bin
hangs, it just sits there consumming around 20% of the CPU with no
change to memory usage, bytes read or anything else.
Any hints?
Thank you,
Daniel Brosseau
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
