[jacorb-developer] When an IOR has two similar profiles, COMM_FAILURE is thrown instead of TRANSIENT

[Nick Cross]

Hi,

This mailing list won't accept patches. However a pull request to github 
would be very welcome!

Thanks

Nick


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 !
>
> Best,
> 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
>> the
>> 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
>> and
>> then the two profiles become identical.
>>
>> In this situation, if the server is offline and a call to it is made,
>> the
>> 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
>> that
>>     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
>> proxy
>>     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
>> iterator,
>> I guess. Besides not accounting for the presented problem, I'm not sure
>> it
>> 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
>> JacoTest
>> which was already failing before), but I'm not sure this is correct or
>> the
>> right fix. I did this trying to mimic DefaultProfileSelector's
>> behaviour
>> before the bug was introduced on commit
>> c6570906b3fa05a4afa420033188b428ccce612c.
>>
>> One other thing that caught my attention was the lastUsedProfile
>> variable
>> inside the ParsedIOR class. From what I could understand code outside
>> this
>> class should call markLastUsedProfile() when a profile is used, but in
>> the
>> case of an exception like TRANSIENT it's not called and there's even
>> debug
>> logging that's maybe relying on it (Delegate.java line 1728). If I
>> remember
>> correctly this seems to also occur in other parts of the Delegate
>> class. If
>> markLastUsedProfile could be private and called from the other
>> ParsedIOR
>> methods it would fix this problem but I don't know if it's possible
>> without
>> spending considerable more time to understand the code better.
>>
>> Any help would be appreciated, I'm attaching a patch with the tested
>> fix
>> and a test case to reproduce the problem.
>>
>> Thanks,
>>
>> Carlos
>>
>> 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
>> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
>>
>>
>> _______________________________________________
>> jacorb-developer maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
>> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer