Tim,
thank you for your response.
I will ask the customer to send the complete sun-acc.xml and domain.xml
file, so you can see that nowhere a hostname is used. A ping to the
hostname on both, client and server, runs on the correct address. Also I
will add the complete logging info, not just the part containing the
exception. Is it correct that I have to change this line to enable INFO
logging:
<log-service file="" level="WARNING"/>
to
<log-service file="" level="INFO"/>
?
Thanks
Markus
Von: Timothy.Quinn_at_Sun.COM [mailto:Timothy.Quinn_at_Sun.COM]
Gesendet: Dienstag, 25. August 2009 15:08
An: Markus Karg
Cc: dev_at_glassfish.dev.java.net; kcavanaugh_at_dev.java.net
Betreff: Re: Where does ACC's CORBA stack get the server's IP from?
Hi, Markus.
Normally an early part of the client logging output shows what endpoint
host and port the ACC is providing to the ORB for making that initial
connection. Is that information displayed? (It's done at the INFO
logging level.)
You mentioned that the customer has updated the sun-acc.xml with the
numeric IP address. Until I got to that point in your message I was
going to have the customer check to see if the client had a hosts file
that was overriding the DNS value for the hostname with perhaps the old
value. But if the sun-acc.xml now specifies the numeric IP address that
cannot be the problem. Plus you also mentioned that the client and
server hosts files seem OK.
What does the domain.xml on the server have in the
iiop-service/iiop-listener_at_address attribute?
- Tim
Markus Karg wrote:
We have an urgent problem related to ACC's CORBA internals which I hope
can be answered soon by the CORBA experts in this forum. I will post the
solution later in the user forum if it is resolved to reduce cluttering
of the forum with lots of internals.
There is a customer running GlassFish v2ur2 with a remote ACC. All
worked well. Due to internal subnet restructuring, now his server host
has changed its IP address (CORRECT (new) is 192.168.200.1. He now has
the trouble that his remote ACCs start up, try to connect to the server,
but this trial is using a WRONG IP (10.31.140.2 Port 3700), as shown
below. When we do a ping on the server's hostname from this client, it
shows the CORRECT (new) IP of the server - so it is not a general DNS
problem!
So the question is: Where does CORBA get this WRONG IP from (obviously
not from DNS, since ping is working)? And how to convince the ACC to use
the CORRECT (new) IP (we have replaced the hostname in the client's
sun-acc.xml by the correct IP, but does not work)?
We checked DNS and etc/hosts on client and server, with no solution.
Thanks!
Markus
.java:105)
at
com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSock
etFactory.java:332)
... 19 more
24.08.2009 08:17:51
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImp
l <init>
WARNUNG: "IOP00410201: (COMM_FAILURE) Verbindungsfehler: socketType:
IIOP_CLEAR_
TEXT; Hostname: 10.31.140.2; Anschluss: 3700"
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(O
RBUtilSystemException.java:2690)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.connectFailure(O
RBUtilSystemException.java:2711)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(
SocketOrChannelConnectionImpl.java:261)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(
SocketOrChannelConnectionImpl.java:274)
at
com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.create
Connection(SocketOrChannelContactInfoImpl.java:130)
at
com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.begin
Request(CorbaClientRequestDispatcherImpl.java:192)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaC
lientDelegateImpl.java:181)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClie
ntDelegateImpl.java:325)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112)
at
org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java
:69)
at
com.sun.enterprise.naming.SerialContext.narrowProvider(SerialContext.
java:131)
at
com.sun.enterprise.naming.SerialContext.getCachedProvider(SerialConte
xt.java:247)
at
com.sun.enterprise.naming.SerialContext.getRemoteProvider(SerialConte
xt.java:227)
at
com.sun.enterprise.naming.SerialContext.getProvider(SerialContext.jav
a:160)
at
com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:398
)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
com.sun.enterprise.naming.NamingManagerImpl.bindObjects(NamingManager
Impl.java:626)
at
com.sun.enterprise.appclient.AppContainer.preInvoke(AppContainer.java
:146)
at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithMod
uleSupport.java:383)
at
com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithMod
uleSupport.java:259)
at com.sun.enterprise.appclient.Main.main(Main.java:200)
Caused by: java.lang.RuntimeException: java.net.ConnectException:
Connection tim
ed out: connect
at
com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSock
etFactory.java:347)
at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(
SocketOrChannelConnectionImpl.java:244)
... 18 more
Caused by: java.net.ConnectException: Connection timed out: connect
at sun.nio.ch.Net.connect(Native Method)
at
sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility
.java:105)
at
com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSock
etFactory.java:332)
... 19 more
24.08.2009 08:18:22
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImp
l <init>