The loop is called twice, in the first iteration the locals are:

rt_stub: :00CEE7D8
priority_model_policy: { :00CEEB60 }
bands_policy: { NULL }
all_endpoints_are_valid: 0 (0x00000000)
match_priority: 1 (0x00000001)
match_bands: 0 (0x00000000)
client_thread_priority: 0 (0x0000)
min_priority: 0 (0x0000)
max_priority: 0 (0x0000)
ep: :00CEE468
val: NULL
r: :012CFB1C
this: :00CD3C34
endpoint_priority: -1 (0xFFFF)

The second time:

rt_stub: :00CEE7D8
priority_model_policy: { :00CEEB60 }
bands_policy: { NULL }
all_endpoints_are_valid: 0 (0x00000000)
match_priority: 1 (0x00000001)
match_bands: 0 (0x00000000)
client_thread_priority: 0 (0x0000)
min_priority: 0 (0x0000)
max_priority: 0 (0x0000)
ep: :00CEE758
val: NULL
r: :012CFB1C
this: :00CD3C34
endpoint_priority: -1 (0xFFFF)

The value of r.profile ()->endpoint_count () is with both cards enabled 2, so
the following will be false:
          r.profile ()->endpoint_count () == 1 &&
          endpoint_priority == TAO_INVALID_PRIORITY)

But as expected with 1 card enabled the endpoint card is 1, endpoint priority is
TAO_INVALID_PRIORITY so then we get a true back and select an endpoint

It seems it is related to this change below. The changelog already says already
TAG_ALTERNATE_IIOP_ADDRESS can be used when not using RTCORBA. In practice this
means that each RTCorba application which runs on a system with multiple network
cards will have problems. Disabling for each test/application doesn't seem real
handy for end users, can't the RTCorba library indicate in some way that this
isn't allowed to be used and then disable it.

Fri Jun 10 07:51:36 2005  Phil Mesnier  <mesnier_p@ociweb.com>

        * docs/Options.html:
        * tao/IIOP_Acceptor.cpp:
        * tao/IIOP_Profile.cpp:
        * tao/IIOP_Profile.h:
        * tao/ORB_Core.cpp:
        * tao/Tagged_Components.cpp:
        * tao/Tagged_Components.h:
        * tao/params.cpp:
        * tao/params.h:
        * tao/params.i:
        * tao/PortableServer/Default_Acceptor_Filter.cpp:
        * tests/AlternateIIOP:
        * utils/catior/catior.cpp:

          Added support for TAG_ALTERNATE_IIOP_ADDRESS to combine many
          endpoints into a single profile when not using RTCORBA. This may
          be overridden by using the ORB_init argument
          -ORBUseSharedProfiles 0. It is enabled by default. Unlike the
          TAO-specific TAO_TAG_ENDPOINTS, the TAG_ALTERNATE_IIOP_ADDRESS
          component contains a single host:port pair, but many such
          components may be added to a profile to carry as many endpoints
          as required.

What is the background that with RTCorba when there is just one endpoint in the
profile that we then use that endpoint, when multiple are theres we don't use any? C

I have directly contacted Phil to ask if he can have a look at this.

raised priority and severity

The intent of the new feature for TAG_ALTERNATE_IIOP_ADDRESS is to provide
greater interoperability in a non-RT, mixed ORB environment. This feature has
been part of TAO 1.3a for a long time, albeit with an error that caused it to
encode only a single alternate address, if any were present.

Regarding RTCORBA, IIOP_Profile has a method, encode_endpoints(), which would
create the TAO-specific TAO_TAG_ENDPOINTS to collect the endpoint information
with priority. When the original (1.3a) version of TAG_ALTERNATE was
implemented, this method was extended, and with a guard to attempt to prevent
the generation of a TAO_TAG_ENDPOINTS if the base endpoint priority was
TAO_INVALID_PRIORITY. This then is called by the non-rt POA when constructing
profiles, in the same manner as the RT_POA.

I'm not able to reproduce your error locally, as I do not have a windows machine
with dual interface cards. (My Linux machine with 2 cards isn't recoginzing the
second card for some reason.)

I believe I understand the situation behind the error, and I have a couple of a
possible solutions. The simplest solution is to take away the priority test, and
always encode a TAO_TAG_ENDPOINTS component as well as any
TAG_ALTERNATE_IIOP_ADDRESS components. The alternative is to add a new method to
the Profile base for encoding non-RT alternate endpoints. I would move the new
encoding support to this method.

Do you have an opinion on which approach might be preferable?

Phil, first a question, is the restriction that just one extra endpoint is added
already resolved in the current cvs version or needs that to be fixed? 

This problem seems to be unrelated to windows. Any machine with multiple network
cards will give a failure. Both cards must be connected to the network and up.

I have to think a little bit more about what I think the best approach is, but I
also want to get some feedback from others (Bala/Ossama/Irfan) before making any
decisions on this.

For this specific case, it seems we have a client set priority model, there are
no bands, then it seems to me that an endpoint with invalid priority maybe be
used without problem (that is the default). Of course an endpoint with the
priority of the client requested is better. Maybe the loop should be rewritten.
First try to find one that really matches and if no one is found then in some
cases an endpoint using an invalid priority may be used.

I will think a little bit more on this but at this moment I don't think the
encoding is wrong, but more the selection of the endpoint in RTcorba

In practice this means then removal of the following in the if
          r.profile ()->endpoint_count () == 1 &&
          endpoint_priority == TAO_INVALID_PRIORITY)

And add an extra loop if we didn't find a endpoint in the first loop.

FWIW, I am able to reproduce the bug reported below. It occurs even without the
TAG_ALTERNATE_IIOP_ADDRESS code, so I don't think that is the cause of the problem.

However, I think that I should separate out the different forms of endpoint
encodings so that RT-CORBA always gets the TAO_TAG_ENDPOINT component and non-RT
will get TAG_ALTERNATE_IIOP_ADDRESS components, as appropriate.

I have committed a change to the way TAG_ALTERNATE_IIOP_ADDRESS (TAIA)
components are generated. This change separates the classic RT CORBA behavior
related to encoding multiple endpoints in a single profile from the new TAIA
behavior. Now TAIA is only available when not using RTCORBA and when the new ORB
initialization option, -ORBUseSharedProfile 1, is supplied. The default behavior
is as it was, to generate separate profiles for each endpoint.

I am reassigning this back to tao-support so that further work may be done on
improving the performance of RTCORBA and multiple interfaces.

Lowering priority. The crashes are now gone, but we should look at the RTCorba
endpoint selection.