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

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