Another thing to look at is thread management. We do something similar in Java and we started out with lots of sporadic problems which turned out to be two threads trying to process documents on the same instance of OpenOffice at the same time. We wrote a simple resource handler similar to the way connection pools work for JDBC connections so that we could check out connection to OpenOffice, use it, then release it back to the pool. This way only one thread ever accessed one instance of OpenOffice at a time. We usually use 4 but it is configurable to as many as your box can handle. We have run this with large numbers of threads active and processing documents at the same time on multi-cpu machines without problem.
Still, we did it in Java, doesn't mean there isn't an issue with the C# binding. -----Original Message----- From: so-ham02-newsgate...@sun.com [mailto:so-ham02-newsgate...@sun.com] On Behalf Of Stephan Bergmann Sent: Thursday, November 11, 2010 8:25 AM To: dev@api.openoffice.org Cc: jtal...@spudsoft.co.uk Subject: Re: [api-dev] Access violation in urp_uno when using API from C# on Windows 7 On 11/11/10 13:07, Jim Talbut wrote: > In this instance I've got 8 soffice.bin processes running, and the test > has run through 40+ documents 12 times before hitting the issue. > Also if I reconfigure to run only a single soffice.bin process I don't > hit the problem (or at least, not in a reasonable timeframe). > As a result it looks like a race condition of some kind within the > urp_uno worker thread. > > I suspect the issue relates to XBridge.getInstance function because > whenever it occurs there is a call stack like this on one of the other > threads: > 0cddda30 09e738bb <Module>.cli_uno.Bridge.call_uno(cli_uno.Bridge*, > _uno_Interface*, _typelib_TypeDescription*, > _typelib_TypeDescriptionReference*, Int32, _typelib_MethodParameter*, > System.Object[], System.Type[], System.Object ByRef) > 0cdddb3c 09e72a20 > cli_uno.UnoInterfaceProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage) > > 0cdddc8c 5c69a25e > System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(System.Runtime.Remoting.Proxies.MessageData > ByRef, Int32) > 0cdddf1c 5de12356 [TPMethodFrame: 0cdddf1c] > unoidl.com.sun.star.bridge.XBridge.getInstance(System.String) > 0cdddf2c 09e722ad NodConverter.OpenOfficeConverter.Channel.Start(Int32) > [C:\Users\njt\Projects\NodConverter\NodConverter.OpenOfficeConverter\Channel.cs > @ 107] > > In my code soffice.bin instances are started and stopped and different > times, so there were multiple calls to loadComponentFromURL being made > at the same time as this crash (though on different instances of > soffice.bin). > > I'd be very grateful for any help sorting this out, and of course I can > provide more information (including a minidump if you want) as requested. The crash is in the client, right? The probably most typical usage scenario for URP is to have only a single URP connection active per process, so it might well be that there hides a problem in the code when using multiple connections simultaneously. (XBridge.getInstance is called when a new URP connection is established; maybe the problem hides there somewhere.) I know of some problems with the URP bridge during shutdown (like <http://qa.openoffice.org/issues/show_bug.cgi?id=114675> and <http://qa.openoffice.org/issues/show_bug.cgi?id=113679>), so am currently doing a rather massive re-write of the URP code at <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb135>. Maybe that will help, once it is ready. ;) Apart from that, to track down your problem, it would be necessary to have better stack traces, including local symbols, preferably even debugger support enabled. You only get this if you build OOo yourself, but I do not know whether that is something you feel comfortable doing? -Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
