[jacorb-bugs] [Bug 932] New: ServantDelegate network overheads when using interceptors can kill/DDoS DNS service

[bugzilla-daemon at jacorb.org]

http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=932

           Summary: ServantDelegate network overheads when using
                    interceptors can kill/DDoS DNS service
           Product: JacORB
           Version: 3.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ORB
        AssignedTo: jacorb-bugs at lists.spline.inf.fu-berlin.de
        ReportedBy: roger.c.hayes at baml.com


Hi

Going from JacORB 2.3.0 to 3.0 (and 3.1) a change was made to
ServantDelegate.this_object().  By comparison with 2.3.0, in 3.0 an additional
_duplicate() invocation is made before returning the Object - comment says that
this addresses a possible interaction between the object reference cache and
generated code.

  return (poa.servant_to_reference(self))._duplicate();

The issue that I have seen is that this _duplicate() invocation carries a very
high and in my view unworkable overhead - eventually we invoke
ORB._getDelegate(new ParsedIOR(orb, toString()) - as well as other processing,
the ParsedIOR construction may involve a DNS access.

My application uses interceptors.  On the server side, a very common invocation
made in interception points is ServerRequestInfo.get_server_policy().  The
ServerRequestInfoImpl implementation makes a call to
ServantDelegate._get_policy() parameterised with the servant _this_object(),
which then calls ServantDelegate.this_object().  The result is not actually
used but nevertheless the call is made; when using JacORB 3.0 the result is
that I get a DNS invocation on every request to the server.  (This may not be
noticed straight away but network admins will be in touch - I actually also ran
into problems when the greatly increased frequency of lookups resulted (I
believe) in servers hitting JVM bug 7012768).  I suspect that this is going to
be a very common scenario in applications using interceptors.

Although I probably need to look at the code more closely, I'm not 100%
convinced that the _duplicate() has any effect - with caching enabled, the
eventual ORB._getDelegate() use the stringified IOR as the cache key - assuming
"dead" uninited IOR chars aren't an issue in ParsedIOR.getIORString() surely
this will just be the same Object that we had in the first place?  (Also noted
in passing that the caching is disabled by default and the property
jacorb.reference_caching needed to enable it doesn't seem to be documented
outside the source).

For the time being I've commented the _duplicate() out in my local JacORB.  I
wonder if anyone has thoughts on the possible side effects of this (or how the
original issue can be worked around without incurring the CPU or network
overhead)..

Regards, and thanks in advance for any opinions

Ted Hayes


-- 
Configure bugmail: http://www.jacorb.org/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.