Issue 116038 - rewrite binary URP bridge
Summary: rewrite binary URP bridge
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: 4.0.0
Assignee: Stephan Bergmann
QA Contact: issues@udk
Depends on:
Reported: 2010-12-10 10:36 UTC by Stephan Bergmann
Modified: 2013-05-24 17:58 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

experimental patch to make oneways async (2.54 KB, patch)
2011-05-11 19:43 UTC, Stephan Bergmann
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2010-12-10 10:36:40 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.
Comment 1 Stephan Bergmann 2010-12-10 10:37:31 UTC
Comment 2 Stephan Bergmann 2010-12-10 10:41:55 UTC
The relevant code will be obsoleted through issue 116038.
Comment 3 Stephan Bergmann 2010-12-10 10:42:32 UTC
[<#desc3> is of course bogus; ignore it]
Comment 4 Stephan Bergmann 2011-01-27 10:31:38 UTC
fixed as <>
Comment 5 Stephan Bergmann 2011-01-31 14:52:56 UTC
tested new implementation directly via testtools tests and indirectly via
smoketestoo_native and subsequenttests (that use URP to communicate with the
soffice executable)
Comment 6 olistraub 2011-05-06 14:11:51 UTC
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.


Is the asynchronous oneway functionality not supported any more?
Comment 7 Stephan Bergmann 2011-05-06 19:33:45 UTC
@olistraub:  Yes, support to enable async oneways has silently been dropped from the binary URP bridge.  Does that cause a problem for you?
Comment 8 olistraub 2011-05-10 05:31:36 UTC
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.
Comment 9 Stephan Bergmann 2011-05-11 19:43:59 UTC
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.
Comment 10 olistraub 2011-05-12 06:05:24 UTC
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
Comment 11 olistraub 2011-05-20 07:01:58 UTC
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
Comment 12 Stephan Bergmann 2011-05-20 07:22:50 UTC
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?
Comment 13 olistraub 2011-05-20 08:08:43 UTC
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.
Comment 14 olistraub 2011-06-08 13:40:23 UTC
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.
Comment 15 Oliver Brinzing 2013-05-24 17:58:45 UTC