RE: [api-dev] Xstorable.storeToUrl locks soffice.bin
java.io.BufferedReader.readLine:362 ooo.connector.server.OOServer$1.run:143 'Tread-1' suspended at 'sun.print.Win32PrintServiceLookup.notifyPrinterChange' Hidden Source Calls sun.print.Win32PrintServiceLookup.notifyPrinterChange sun.print.Win32PrintServiceLookup.access$100:32 sun.print.Win32PrinterServiceLookup$PrinterChangeListener.run:302 I hope this helps in finding where the problem lies. Could you please signal me if there is something I am doing wrong? Regards, Daniel -Original Message- From: mikhail.voite...@sun.com [mailto:mikhail.voite...@sun.com] Sent: February 24, 2009 4:19 AM To: dev@api.openoffice.org 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: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
RE: [api-dev] Xstorable.storeToUrl locks soffice.bin
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: mikhail.voite...@sun.com [mailto:mikhail.voite...@sun.com]
Sent: February 24, 2009 4:19 AM
To: dev@api.openoffice.org
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
Re: [api-dev] Xstorable.storeToUrl locks soffice.bin
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: mikhail.voite...@sun.com [mailto:mikhail.voite...@sun.com]
Sent: February 24, 2009 4:19 AM
To: dev@api.openoffice.org
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
Re: [api-dev] Xstorable.storeToUrl locks soffice.bin
) sun.nio.cs.StreamDecoder.readBytes:264 sun.nio.cs.StreamDecoder.implRead:306 sun.nio.cs.StreamDecoder.read:158 Owned Monitor: java.io.InputStreamReader(#625) java.io.InputStreamReader.read:167 java.io.BufferedReader.fill:136 java.io.BufferedReader.readLine:299 java.io.BufferedReader.readLine:362 ooo.connector.server.OOServer$1.run:143 'Tread-1' suspended at 'sun.print.Win32PrintServiceLookup.notifyPrinterChange' Hidden Source Calls sun.print.Win32PrintServiceLookup.notifyPrinterChange sun.print.Win32PrintServiceLookup.access$100:32 sun.print.Win32PrinterServiceLookup$PrinterChangeListener.run:302 I hope this helps in finding where the problem lies. Could you please signal me if there is something I am doing wrong? Regards, Daniel -Original Message- From: mikhail.voite...@sun.com [mailto:mikhail.voite...@sun.com] Sent: February 24, 2009 4:19 AM To: dev@api.openoffice.org 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: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail
[api-dev] Xstorable.storeToUrl locks soffice.bin
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: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Xstorable.storeToUrl locks soffice.bin
Hi Daniel, Really what I would like to know is how to avoid the hanging soffice.bin. Any hints? I have two ideas: 1. After doing an action like opening, printing, storing or closing, what happens it you let your main Thread sleep for half a second? This avoids some deadlocks in my case. 2. If you can reproduce the deadlock, can you strace it? I think it might be interesting for the OOo team. Good luck, Tobias - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
