[jacorb-developer] When an IOR has two similar profiles, COMM_FAILURE is thrown instead of TRANSIENT
jacorb at goots.org
Thu Nov 10 15:03:08 CET 2016
This mailing list won't accept patches. However a pull request to github
would be very welcome!
On 10/11/16 14:00, Amadeu A. Barbosa Junior wrote:
> Hi list,
> I think Carlos Eduardo forgot that attachment. I work with him. I'm
> attaching the patch now.
> This problem affects JacORB 3.7 and 3.8 !
> Amadeu A. Barbosa Junior
> On 2016-10-28 09:19, Carlos Eduardo wrote:
>> In a client, if the server's IOR is provided with two almost identical
>> profiles that differ only in the host form, for example one containing
>> host in the form of an IP address and the other containing the host's
>> machine name, JacORB will resolve the machine name into its IP address
>> then the two profiles become identical.
>> In this situation, if the server is offline and a call to it is made,
>> following occurs (when using DefaultProfileSelector):
>> 1. The call is attempted using the first profile's address and a
>> TRANSIENT is thrown.
>> 2. Before returning the call to the client application JacORB sees
>> there are more profiles so proceeds to select the next one.
>> 3. Since both are equal, DefaultProfileSelector returns null, which
>> nullifies the effectiveProfile in the ParsedIOR object.
>> 4. This leads to a COMM_FAILURE in the next call using the same
>> object, when I believe it should still be a TRANSIENT. The proxy
>> does not
>> recover from this and will forever throw COMM_FAILURE.
>> The logic to return null if two profiles are equal in
>> DefaultProfileSelector seems to be there to prevent a loop in the
>> I guess. Besides not accounting for the presented problem, I'm not sure
>> should return null in any case where there are profiles to try since
>> ParsedIOR puts any return it gets into effectiveProfile.
>> Just removing lines 95-100 from DefaultProfileSelector.java fixes the
>> COMM_FAILURE and passes the entire JacORB test suite (except for
>> which was already failing before), but I'm not sure this is correct or
>> right fix. I did this trying to mimic DefaultProfileSelector's
>> before the bug was introduced on commit
>> One other thing that caught my attention was the lastUsedProfile
>> inside the ParsedIOR class. From what I could understand code outside
>> class should call markLastUsedProfile() when a profile is used, but in
>> case of an exception like TRANSIENT it's not called and there's even
>> logging that's maybe relying on it (Delegate.java line 1728). If I
>> correctly this seems to also occur in other parts of the Delegate
>> class. If
>> markLastUsedProfile could be private and called from the other
>> methods it would fix this problem but I don't know if it's possible
>> spending considerable more time to understand the code better.
>> Any help would be appreciated, I'm attaching a patch with the tested
>> and a test case to reproduce the problem.
>> PS: Sorry for not making the test case completely independent, it uses
>> resources from bug983 (hello interface with a sayGoodbye method that
>> deactivates the server) and orb (IOR Interceptor to insert the second
>> identical profile) test suites. I also refactored the ClientServerSetup
>> class a bit to make things easier.
>> jacorb-developer maillist -
>> jacorb-developer at lists.spline.inf.fu-berlin.de
>> jacorb-developer maillist - jacorb-developer at lists.spline.inf.fu-berlin.de
More information about the jacorb-developer