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]
