Bugs item #569305, was opened at 2002-06-15 09:35 Message generated for change (Comment added) made by letiemble You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=569305&group_id=22866
Category: None Group: None >Status: Closed >Resolution: Remind Priority: 5 Submitted By: Samuel Terrell (j3110) >Assigned to: Laurent Etiemble (letiemble) Summary: Server IP detection causes problems Initial Comment: By default, on some Linux distributions, for performance and other reasons (some interfaces have dynamic IP's but the hosts ip shouldn't change), the host name of the local machine is configured to point to 127.0.0.1. When connecting through JNDI from a remote machine, the IP set in jndi.properties is overwritten with 127.0.0.1 on the client side. Obviously, this causes the client to fail connecting to the server. Other servers, Apache for example, warn the user that this is probably undesired behavior and allow a way to manually override the local IP with an option in the configuration files. ---------------------------------------------------------------------- >Comment By: Laurent Etiemble (letiemble) Date: 2003-10-17 14:04 Message: Logged In: YES user_id=437455 This is a known issue. See the complete FAQ here : http://www.jboss.org/thread.jsp?forum=67&thread=8092 ---------------------------------------------------------------------- Comment By: alan shields (alanshields) Date: 2003-05-31 09:19 Message: Logged In: YES user_id=575453 Ive had a couple of issues with this where the ip address of the name returned by hostname is not the address of the server. With an AIX HA cluster this appears to be quite common, eg with a two node HACMP configuration: servera - hostname of machine a serverb - hostname of machine b service - service name machine a's host file ... ... 192.168.42.100 service 192.168.42.101 servera ... ... machine b's host file ... ... 192.168.42.100 service 192.168.42.102 serverb ... ... the 101 & 102 addresses exist at boot up, once one of the two machines takes control of the service address it's boot address is no longer available, now when jboss starts up (on machine a for instance) it looks up the hostname (servera) then looks up the ip address for that (192.168.42.101) then attempts to connect to itself on that address and fails. ---------------------------------------------------------------------- Comment By: Samuel Terrell (j3110) Date: 2003-01-16 20:56 Message: Logged In: YES user_id=563515 Being a developer too, I've given this much thought. I assume the server sends the IP back because of the possibility that the bean requested is on a different server in a cluster or the JNDI server has a different IP than the container. The root of this problem is that DNS records don't always exist for a particular server. Some people run load balaners or multihomed networks or firewalled networks that have a different IP than the local machine for the DNS record. In these situations, all the traffic that is to get to the "Bob" domain will hit an IP on a router, firewall, or load balancing system. From there, it will forward it (or not) to a particular client who has no dns record. Usually, it is a 192.168.* or 10.* address allocated for this particular purpose. This problem, as another poster mentioned, is compounded when you have multiple internet connections, multi-homed. In this situation, you will listen on a virtual IP address, but you want your clients to connect to any address it can of a list that MUST be entered by the admin. There is really no way of detecting these reliably, and it is a very common situation for anyone that wants true HA and performance. For example, most ISP's that offer coorperate web hosting that is reliable will have a connection through Sprint and one through Qwest or MCI or anyone else. That way when one of the backbones of the internet gets DOS'd/struck by lightening, only the poor saps that use their backbone will not have a connection to the server. What we end up with, in order to make a server work in all conditions, is slightly complicated. Other servers get away with this because they allow you to pass back host names that use DNS to resolve to the multiple IP's they connect to. This may work with JBoss, but it will not know which IP to listen on, and it can't listen on all interfaces. If it listens on all interfaces, then it will interfere with multipath routing daemons. What we need is a place to specify ListenIP, and a place to specify Hostname that may be different from the system hostname. Look at the JavaDoc for ServerSocket's constructors. They have a special constructor for this situation. The ideal solution is to be able to overide the defaults and set a list of ip's to bind to and listen on, and to have a seperate list that can be overridden to specify a list of IP's that clients will connect to. I say IP's for both because if you use DNS, then 1 DNS name could refer to all the servers in the cluster. If your architecture forwards requests from one server to another, then you will be ok with this, but some people don't want/have a DNS name for their servers as well. I hope I was more informative and helpful this time around (now that I've thought out the problem a little more). Make whatever decision you think is best, in the past you've all done a great job of balancing the needs of your clients! ---------------------------------------------------------------------- Comment By: Jens Deponte (dirkgently) Date: 2003-01-16 14:32 Message: Logged In: YES user_id=671538 Recently I came across the same bug and changes my /etc/hosts file as a workaround. Although everything went fine since, I'm not quite satisfied with this solution. Setting the servers IP address via a config file seems to be a good solution, but it fails for a multihomed host behind a NAT firewall. This might be a uncommon configuration, but by now I don't see a reason, why the server should deliver its IP address anyway. If the client could connect with the address configured on client side, why can't it continue to do so? Any suggestions? Otherwise I'll have to ask the source code :-( Details: The server I used is a Linux (SuSE 8.1) box configured using DHCP. The default configuration of this distribution with DHCP is hostname => 127.0.0.2. You can discuss if this is ok or not, but the bug should also be reproducible with any JBoss installation behind a NAT firewall. ---------------------------------------------------------------------- Comment By: Samuel Terrell (j3110) Date: 2002-06-19 09:59 Message: Logged In: YES user_id=563515 You would think that since you specify the IP in the jndi.properties file that the client could connect to the server, and it does for a brief moment. In that moment, apparently it retrieves the incorrect IP address from the JNDI server. The reason I say this is that I get a connection refused error on the client. It explicitly states that the error occurred while trying to connect to 127.0.0.1, and the error is thrown in the JNDI lookup of anything from a remote machine. I thought this was funny and set the server's host name to point to 1.1.1.1 in /etc/hosts, and it returned that address. As soon as I noticed this behavior, I was able to set the server's host name to point to the same IP as it is in the jndi.properties file. The client worked fine after I did so, but other users of JBoss probably will never notice this behavior, and thus, think that JBoss is to blame. Technically, JBoss should probably fail if it retrieves an IP in the 127.0.0.0/8 range, because it is certain to not work from remote machines. In the very least it should warn the unsuspecting administrator that he/she needs to fix the name resolution so that it doesn't end up with 127.0.0.1 for the host name. I'll leave the judgment of what the proper behavior should be up to someone else. I'm certain that this behavior wasn't intended as it causes remote connections to fail by default to a Linux server running JBoss. Basically, it isn't necessary that the server sends the IP address. In fact, if it didn't, this problem wouldn't occur. I have confirmed this behavior on several machines. If you want to see the behavior yourself: Set up JBoss on Linux. Type “hostname”. Edit /etc/hosts. Make sure the only line with the return of the “hostname” command is the same line as 127.0.0.1. Run JBoss on the server. Edit jndi.properties on the client machine (must be remote, not just different VM) . Set the IP to the proper IP of the server. Then try to run your client application. If you properly configured Linux, you won't have to check the “hostname” command against /etc/hosts, as it is the proper behavior of Linux to tell applications to use the local interface for local connections. The problem arises when servers like JBoss use this method of getting the IP to tell the client. You indeed will have the same problem from apache if the host name of the local system doesn't lookup via DNS, not the hosts file. But, when you have this problem from apache, it will say “Cannot find server name, using 127.0.0.1” as well as giving you a method for overriding this automatic detection mechanism in the configuration file. ---------------------------------------------------------------------- Comment By: Joao Pedro Clemente (jpcl) Date: 2002-06-18 21:35 Message: Logged In: YES user_id=169196 For what I've read from other J2EE platform manuals, I guess this happens 'cause of misuse of IP address. I'm not sure if I understood the failure cenario completely, but it seems that this would not happen if the client would use the server name instead of ip address. This is similar to some failures that happen when using a http proxy server that badly resolve dns names, if I'm not mistaken. Is it really necessary that the server sends the IP address to the client? Are you sure this is not a problem of your machines network configuration? Maybe you could give more details on your setup/machine configuration? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=569305&group_id=22866 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
