[omniORB] potential bug: two ORBs with the same endPoint

[Harri Pasanen]

Why do you want to decide the port to pick?
Why don't you just let the underlying OS decide, and use a naming 
service?

-Harri

On Friday 19 May 2006 13:32, Igor Lautar wrote:
> Hi,
>
> On Friday 19 May 2006 13:22, Duncan Grisby wrote:
> > Are you using Windows?  I expect so.
>
> Yes, I forgot to mention it.
>
> > The problem is not with omniORB, it is with Windows'
> > interpretation of the SO_REUSEADDR socket option. omniORB binds
> > using that option so that if a server crashes it is immediately
> > able to rebind to the same address. Unfortunately, Windows allows
> > a process to bind to an address, even if another process is still
> > using it. There's no way to avoid it other than not specifying
> > SO_REUSEADDR, but then people would be complaining that their
> > servers fail to start immediately after a previous run stopped.
> >
> > Unix platforms correctly fail to allow you to bind if another
> > process is already bound.
>
> Ok, so what is the common way to handle this? Because it is to late
> to do proper error handling if OBJECT_NOT_EXIST is returned
> somewhere after ORB initialization, just because port was used. And
> checking if port is used before doing ORB_init does not solve the
> problem (something else could come inbetween checking and ORB_init
> binding to it).
>
> Regards,
> Igor
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list


Privileged or confidential information may be contained in this message.  If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Trema does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Trema does not accept liability for any damage sustained as a result of viruses.  Statements in this message or attachments that do not relate to the business of Trema are neither given nor endorsed by the company or its directors. A list of Trema's directors is available on our web site: www.trema.com