[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Java dynamic domain name workaround
it seems that most layer 4 apps don't first check if a machine they want to contact is reacheable in layer 3. For instance a telnet foobarbar.com (be carefull, there is a fobar.com host :-) ) has it's normal layer 4 timeout even if a ping to foobarbar.com would receive a host unknown icmp message. It get's even worse if the host exists in the domain name system but is down. Here we have standard IP timeout... So from my point of view resolvers should cache IP-Addresses or hostnames (getAddrByHost) for only a short period of times. In local networks there should be caching nameservers/forwarders which should cache the entries and adhere to the standard DNS timeout rules (expiration, zone serial number changes etc.). In general I think it is a bad idea for a resolver to cache the entries for a long time. Even if an IP-Address is reachable on layer 3 it can mean nothing since - as Andre said - dynamic addresses are recycled, thus you could contact the same Address but intend to contact another host. Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:richard.jacob@de.ibm.com |---------+----------------------------> | | David Ward | | | <david.ward@oracl| | | e.com> | | | | | | 06/24/2003 03:46 | | | PM | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Rich Thompson/Watson/IBM@IBMUS | | cc: wsrp-interop@lists.oasis-open.org | | Subject: Re: [wsrp-interop] Java dynamic domain name workaround | >--------------------------------------------------------------------------------------------------------------------------------------------------| I noticed that the networking layer wasn't immediately failing - it was just timing out after a very long time. So it might still make sense to flush before a failure. Rich Thompson wrote: I agree, but usually one can detect the failure to open within the networking layer. This reasonably contains where one would instruct the resolver to flush any caching for the failed ip address. Rich Thompson Andre Kramer <andre.kramer@eu.citrix.com To: Rich > Thompson/Watson/IBM@IBMUS, wsrp-interop@lists.oasis-open.org cc: 06/24/2003 09:01 AM Subject: RE: [wsrp-interop] Java dynamic domain name workaround IP addresses get recycled or don't provoke ICMP messages, so the error can be above the IP (packet) layer. regards, Andre -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: 24 June 2003 13:32 To: wsrp-interop@lists.oasis-open.org Subject: Re: [wsrp-interop] Java dynamic domain name workaround Shouldn't this also be reported as a bug? With increasing use of dynamic addresses, the resolver should be told to flush the cached entry when the IP address is unable to be opened. While this would add a small overhead for when static addresses can't be contacted due to network problems, it eliminates permanently stranding a dynamic ip address. Rich Thompson David Ward <david.ward@oracle.com> To: Richard Jacob <richard.jacob@de.ibm.com> cc: 06/23/2003 06:11 PM wsrp-interop@lists.oasis-open.org Subject: [wsrp-interop] Java dynamic domain name workaround I just wanted to make sure I hadn't left this as a "loose end". Apologies if you have already gathered together this information... Richard Jacob wrote: Btw. could you report today about that problem and your circumvention, so we can pass it to the primer editor's? The problem was that our Java mid tier, which is in our 'DMZ' (Demilitarized Zone?) and doesn't use a proxy, was simply unable to contact the IBM service, even though our test environment which ran through a proxy worked fine. This turned out to be due to the way Java caches IP addresses. The java.net.InetAddress class by default caches IP addresses forever once it has resolved them once. However, the IBM domain name wsrp.dyndns.org actually gets associated with a new IP address every 24 hours, so this was bound to cause problems for our servlet container JVM that stays up forever. If we were running on JDK 1.4, it appears we would be able to control the "time to live" for cached IP addresses through a security policy. However, it seems that the 'private' sun.net.inetaddr.ttl System property mentioned in the JDK 1.4 docs also has the same effect on JDK 1.3. My solution was to edit the config file containing the startup options for the servlet container JVM (in Oracle 9iAS this is in opmn/conf/opmn.xml) so that the sun.net.inetaddr.ttl property is set with a small timeout (I used 120 seconds). E.g. java -Dsun.net.inetaddr.ttl=120 <normal JVM startup options> Regards David -- |--------------------+---------------------------+-----------------------| | David Ward | Oracle European | | | Principal Software | Development Centre | | | Engineer | 520 Oracle Parkway | Email:| | Oracle Portal | Thames Valley Park | david.w| | | Reading | ard@ora| | | Berkshire RG6 1RA | cle.com| | | UK | Tel:| | | | +44 118| | | | 924 | | | | 5079 | | | | Fax:| | | | +44 118| | | | 924 | | | | 5005 | | | | | |--------------------+---------------------------+-----------------------| -- |--------------------+---------------------------+-----------------------| | | | | | David Ward | Oracle European | | | Principal | Development Centre | | | Software Engineer | 520 Oracle Parkway | Email: | | Oracle Portal | Thames Valley Park | david | | | Reading | .ward | | | Berkshire RG6 1RA | @orac | | | UK | le.co | | | | m | | | | Tel: | | | | +44 | | | | 118 | | | | 924 | | | | 5079 | | | | Fax: | | | | +44 | | | | 118 | | | | 924 | | | | 5005 | | | | | | | | | |--------------------+---------------------------+-----------------------|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]