Apache OpenOffice (AOO) Bugzilla – Issue 116038
rewrite binary URP bridge
Last modified: 2013-05-24 17:58:45 UTC
All of issue i114675, issue 113679, issue 73359, issue 71352, issue 58964 (and also Hamburg-internal ones #89623#, #110637#, and #110918#) show that the existing binary URP bridge has known errors, but is also hard to maintain code. Therefore, that bridge should be rewritten from scratch.
.
The relevant code will be obsoleted through issue 116038.
[<#desc3> is of course bogus; ignore it]
fixed as <http://hg.services.openoffice.org/cws/sb138/rev/bf1c8f15eacc>
tested new implementation directly via testtools tests and indirectly via smoketestoo_native and subsequenttests (that use URP to communicate with the soffice executable)
The new bridge does only seem to accept the "urp" protocol string, the options to enable asynchronous oneway-calls ("urp,Negotiate=0,ForceSynchronous=0") leads to an exception. See http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Characteristics_of_the_Interprocess_Bridge Is the asynchronous oneway functionality not supported any more?
@olistraub: Yes, support to enable async oneways has silently been dropped from the binary URP bridge. Does that cause a problem for you?
We're relying on async oneway for some IPC scenarios that send many small write-only messages. The async oneway scenario gave us really good performance numbers Not having the async oneway calls would be a showstopper for upgrading to OO34 for us.
Created attachment 76506 [details] experimental patch to make oneways async @olistraub: The attached patch unconditionally enables async behavior for oneway calls (i.e., it behaves as if you specified "ForceSynchronous=0", but still throws an exception if you specify anything but plain "urp"). It should work (and the testtools/bridgetest tests do succeed), but with OOo itself this cannot really be tested, as already something as simple as executing smoketestoo_native deadlocks---which after all is the reason why async oneway behavior is no longer supported.
Thanks sb, I'll try our test cases with this patch. What about the "official" longterm statement regarding async oneway? I interprete your comment as if you'd prefer to remove this feature completely. Any chance that we can somehow negotiate contiuous (or even extended) support including testcases, ...? Thanks, Oli
A first test of the oneway patch looks very good... our testcases still pass. I'll try to generate some performance numbers next week. Thank you very much, Stefan
Sounds good. Regarding support for the async behavior in OOo, I'm not sure. I would prefer to keep the OOo code as simple as possible. And as for OOo async oneways simply do not work, I would prefer not to re-introduce any support for them. Would it work for you to apply the patch to URE locally?
Yes, this would be possible. But of course we have the same goal than you... keep our customizations simple, rely on 3rd-party code to work out of the box. Our preferred model would be to have async oneway available and tested in OpenOffice. We might volunteer to provide testcases for the async oneway stuff, if this would mean that the async oneway capability stays in OO.
We made some performance tests comparing the old bridge (from OOG680_m5 with some patches applied) against the new bridge. In total, the new bridge is (sometimes considerably) slower: 100x getting service instance (same service): old bridge: 12822us new bridge: 17688us 100x call XMain::run(...) with empty arguments, without code within run: old bridge: 3459us new bridge: 5165us 100x transfer a Sequence<Any> of length 100: old bridge: 5856us new bridge: 8910us 1x transfer 100 Sequence<sal_Int8> of length 1MB each: old bridge: 113086us new bridge: 205018us Async oneway: multiple tests, new bridge is factor 1.5 to 4 slower than old bridge. Details will follow. Stefan, do you see any change for performance improvements? Esp. the factor 2 for transferring large sequences and the oneway numbers hurt us.