Please report new issues athttps://github.com/DOCGroup
I'm not sure if they're meant to work together or not, but it's quite annoying that they seem to be unable work together when using multicast discovery. Judging by very, very brief debugging I did the return value for the ResolveInitialReferences is ALWAYS that of the first looked for (NamingService, InterfaceRepository), and therefore things fail miserably. Is this bug or feature? I could see some justification in calling it a feature, but if so, it's still annoying one.. especially as default IFR implementation doesn't register itself to NS so I need to look it up currently using the .ior file it generates.
I also wrote test code to check this if someone cares. Example output of the symptom: NS IOR is: IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000010000000000000094000000010102002200000069703231322d3232362d3135362d36312e6164736c2e6b706e71776573742e6669007ce43300000014010f004e5550000000150000000001000000004e616d65536572766963650000000000010000004e616d65536572766963650002000000000000000800000001000000004f415401000000140000000166914001000100000000000901010000000000 IFR IOR is: IOR:010000002b00000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000010000000000000094000000010102002200000069703231322d3232362d3135362d36312e6164736c2e6b706e71776573742e6669007ce43300000014010f004e5550000000150000000001000000004e616d65536572766963650000000000010000004e616d65536572766963650002000000000000000800000001000000004f415401000000140000000166914001000100000000000901010000000000 assertion failed at 67 I'll see if I can track it down tomorrow, but according to strace the multicast port used is always the first one used, and therefore (in this case) IFR is requested for within the NS multicast port, and the remote side doesn't care what was asked for and always returns NS IOR.
Applies also for 1.4.3.
Could you attach your test program to this report. People are very busy so we can't make a guarantee when we will have a look. If you have proposed patches, add them to the report as well.
Created attachment 297 [details] Sample code which exhibits the problem
This is also in 5.4.4. The problem code was also found, it's logic being roughly, 'first multicast exact port we get, we use it for rest of traffic', which is downright wrong, as the NameService and IFRService multicast discovery are on different ports. This kludge enabled the test code I provided to work correctly (by overriding the mcast:// prefixes whenever we lookup for a service, I'm not sure if this is correct behavior BUT it works for us): diff -u {ace-5.4.4,ACE_wrappers}/TAO/tao/ORB.cpp --- ace-5.4.4/TAO/tao/ORB.cpp 2005-01-21 18:43:44.000000000 +0200 +++ ACE_wrappers/TAO/tao/ORB.cpp 2005-02-18 15:46:54.000000000 +0200 @@ -1079,7 +1079,7 @@ CORBA::String_var default_init_ref = this->orb_core_->orb_params ()->default_init_ref (); - static const char mcast_prefix[] = "mcast://:::"; + static const char mcast_prefix[] = "mcast://:"; if ((ACE_OS::strncmp (default_init_ref.in (), mcast_prefix,
still valid. string shouldn't be stored into default_init_ref but we should should store the string just for this service request and use that later in the orb core