Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues

Bug 951

Summary:	Ability to disable portable interceptors for local invocations
Product:	JacORB	Reporter:	jmonin <jm.ais40>
Component:	ORB	Assignee:	Mailinglist to track bugs <jacorb-bugs>
Status:	RESOLVED INVALID
Severity:	enhancement	CC:	jacorb
Priority:	P5
Version:	3.2
Hardware:	PC
OS:	Linux

Description jmonin 2013-06-04 05:18:59 UTC

Hello,

We currently use interceptors as a mean to secure date exchanges through encryption.
Originally using Visibroker, we were used to having these interceptors not being called for any local invocation.
Now we note that JacORB does use interceptors even for local calls (yet with a specific optimized behavior).
For critical performance reasons for us, it would be very useful to be able to disable interceptors for local calls.
What we've done so far on our side to work around this, is to disable "interceptors-bound" code portions in servant_preinvoke/post_invoke in the Delegate class, and in the ServantObjectImpl class.

What's your opinion on this specific topic? I couldn't see any obvious mention on what is the preferred behavior in the CORBA 3.1 specifications.

Thanks!

Comment 1 Nick Cross 2013-06-10 08:00:56 UTC

JacORB's behaviour to use interceptors in local calls is specified in the IDL/Java mapping 1.3 2008-01-11 4.21
Is there a particular problem with interceptors being called on local paths?  i.e. could you not do some logical determination in your code to prevent expensive calls if they are not necessary?

Comment 2 jmonin 2013-06-10 08:15:57 UTC

Thanks for your precise answer!
We use interceptors to encrypt/decrypt requests to ensure data security. We obviously don't need that for local exchanges, hence my request.
I see the disabling of interceptors for local calls as the preferred "choice", as it's the best solution performance-wise for us. What process would you recommend in the portable interceptors to know whether the call is local or not? I could maybe do some benchmarks to see if the performance degradation is bearable for us.
Anyway, thanks for your insights!

Comment 3 Nick Cross 2013-06-16 18:01:11 UTC

You could add a check for whether the object is_local ? As per commit 8647cbcf0d9c3fc8f433b82050aa95a764d188e6

Comment 4 Nick Cross 2013-07-18 02:41:12 UTC

Note: bug957 will have a new API isLocalInterceptors() implemented which would allow determination of whether to run code.