[omniORB] A strange IP address appear in omniORB log

[jianping jia]

Hi Duncan,
Thank you for replying. We are using OmniORB 4.0.5. As you suspected, we're
using server name for resolution.  The reference is directly gotten via
string_to_object() and string is formatted as
"corbaloc::giop:servername/identifier". Besides what I mentioned in the
previous email, there is also one strange thing that restarting client can
continue to get communiation with server after the communication fails, so
it should be not due to the server no longer listening. Any issue in client
can cause such error even if the server is listening for connection?
Another strange thing is that two servants in the same server that can be
accessed via INSPOA behave differently. Sometimes, only one of them can be
accessed, while the other one can only get the transient_connectfailed.
Thanks
Best Regards
Jia Jian Ping
On Sat, Mar 20, 2010 at 12:28 AM, Duncan Grisby <duncan at grisby.org> wrote:

> On Wed, 2010-03-10 at 00:08 +0800, jianping jia wrote:
>
> > I have one distributed application that run on two servers(port 66666
> > is defined for INSPOA). Always, it cannot continue communication after
> > a time period of normal running.
>
> [...]
> > Appreciate if any one can tell me what cause the problem.
> > I suspect something like connection leakage cause the  correct port
> > cannot be used, but what can cause that? Besides, why a strange IP
> > address 172.50.10.102:6666(the IP of two servers are 172.50.10.1 and
> > 172.50.10.2 respectviely) appears when error occurs?
>
> What version of omniORB are you using?
>
> It looks as though you are referring to your server by name. Does the
> name resolve to 172.50.10.102 as well as 172.50.10.1?  Alternatively,
> where does the object reference for the server come from?  An object
> reference can contain more than one address.
>
> The TRANSIENT_ConnectFailed exception means the opening a TCP connection
> failed. What is happening on the server at the time the error occurs?
> Normally connection failures are due to the server no longer listening.
>
> Cheers,
>
> Duncan.
>
> --
>  -- Duncan Grisby         --
>  -- duncan at grisby.org     --
>   -- http://www.grisby.org --
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100320/75031c4f/attachment.htm