Re: When an IOR has two similar profiles , COMM_FAILURE is thrown instead of TRANSIENT

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  -  
> [email protected]
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer

_______________________________________________
jacorb-developer maillist  -  [email protected]
https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer