tomcat 6.0.20 different instances with diff ips but same port no 80
Hi Guys, Is it possible by using tomcat 6.0.20 with different instances with diff ips but same port no 80 on one system ??? I have three instances running on one machine named *a,b and c with each has different IPS (192.168.205.10/11/12). * I ran instance a on port 80 (it ran), but when I tried to run another instance b on port 80 ( I got LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in uselt;nullgt;:80)..*.because port 80 is already used * My question is I need to run three applications on port 80 on same machine but different IPs, what is the best way and how ? I really appreciate some one give me some hint (as I can do same think in ISS server) Regards John
Re: tomcat 6.0.20 different instances with diff ips but same port no 80
John Smith wrote: I really appreciate some one give me some hint (as I can do same think in ISS server) http://tomcat.apache.org/tomcat-6.0-doc/config/http.html Look for the address attribute Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6.0.20 different instances with diff ips but same port no 80
John Smith schrieb: Is it possible by using tomcat 6.0.20 with different instances with diff ips but same port no 80 on one system ??? Only one process can bind to any given IP/port combination. I ran instance a on port 80 (it ran), but when I tried to run another instance b on port 80 ( I got java.net.BindException: Address already in use Because that port is already taken for the IP number in question. My question is I need to run three applications on port 80 on same machine but different IPs, what is the best way and how ? Mark provided a link on how to configure different connectors. I made an effort of grokking all this server.xml configuration and have come up with two questions of my own. Please read on. You can use the following XSLT to strip your server.xml of all the helpful comments so you see that it's less frightening than it appears. xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:strip-space elements=*/!-- tabula rasa in -- xsl:output indent=yes/!-- tabula rasa out -- xsl:template match=comment()/!-- weed comments -- xsl:template match=@*|node()!-- identity template -- xsl:copyxsl:apply-templates select=@*|node()//xsl:copy /xsl:template /xsl:stylesheet So you have a Server [1]. It has a couple of Listener elements and GlobalNamingResources. A server may have mulitple Service elements. Don't ask me why you'd want more than one Service elements [2] - because that's what I'd like to ask the experts. Anyone? Anyway, as you can see from [2], a Service represents the combination of one or more Connector components that share a single Engine component for processing incoming requests. Define all the connectors [3] you want for your different IP numbers and ports. They'll all be processed by the single Engine [4], which supports virtual hosting and dispatches incoming requests (based on the HTTP Host header) to a matching virtual host, or, failing that, the default host, which is mandatory both as Engine/@defaultHost and Engine/Host/@name. As a configuration artefact, the Host [5] is decoupled from the IP numbers and only associated with DNS names or aliases. IP numbers and ports are the job of the Connector. Now you could nest Context elements defining your applications inside Host elements - but in Tomcat 6 this is not recommended. Now each Host has its place where to look for applications, which is configured in Host/@appBase. That's where you put your WAR files. Here's my second question: Say I have various Connector bindings set up receiving requests and dispatching them to my single Engine, which has three hosts alpha, beta and gamma. What would be the best way to associate my shiny new second-world.war with all of alpha, beta and gamma? (1) By dropping a copy in each of the different Host/@appBase? (2) By having all three Host/@appBase point to the same location (and then of course put the WAR there)? (3) By some other means? -- Michael Ludwig [1] http://tomcat.apache.org/tomcat-6.0-doc/config/server.html [2] http://tomcat.apache.org/tomcat-6.0-doc/config/service.html [3] http://tomcat.apache.org/tomcat-6.0-doc/config/http.html [4] http://tomcat.apache.org/tomcat-6.0-doc/config/engine.html [5] http://tomcat.apache.org/tomcat-6.0-doc/config/host.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat 6.0.20 different instances with diff ips but same port no 80
From: Michael Ludwig [mailto:m...@as-guides.com] Subject: Re: tomcat 6.0.20 different instances with diff ips but same port no 80 A server may have mulitple Service elements. Don't ask me why you'd want more than one Service elements [2] - because that's what I'd like to ask the experts. Anyone? Seemed like a good idea at the time? If you look inside Tomcat, you'll see that it's a set of nested containers, with Server being the top one, and Service the next layer. You might want to use multiple Service elements if you want to run a single JVM with independent servlet engines inside (think embedded controller, where the number of processes is limited). (1) By dropping a copy in each of the different Host/@appBase? This is probably the best, since it allows independent updating of the .war file for each Host. (2) By having all three Host/@appBase point to the same location (and then of course put the WAR there)? This appears to work, but each Host will be monitoring the same locations for changes (assuming autoDeploy is true), and there might be some timing issues. (3) By some other means? By placing a second_world.xml file in each of the conf/Catalina/[host] directories, with the Context element therein having a docBase attribute pointing to the actual location of the .war file. This is pretty much equivalent to #2, except you can tailor the Context element for each Host, if needed. Regardless, your webapp will be deployed once for each Host. If you don't want that, just use a single Host, and let it field requests for all of alpha, beta, and gamma. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6.0.20 different instances with diff ips but same port no 80
Caldarale, Charles R schrieb: From: Michael Ludwig [mailto:m...@as-guides.com] A server may have mulitple Service elements. Don't ask me why you'd want more than one Service elements [2] - because that's what I'd like to ask the experts. Anyone? Seemed like a good idea at the time? If you look inside Tomcat, you'll see that it's a set of nested containers, with Server being the top one, and Service the next layer. You might want to use multiple Service elements if you want to run a single JVM with independent servlet engines inside (think embedded controller, where the number of processes is limited). Thanks, that sufficiently clarifies it. (3) By some other means? By placing a second_world.xml file in each of the conf/Catalina/[host] directories, with the Context element therein having a docBase attribute pointing to the actual location of the .war file. This is pretty much equivalent to #2, except you can tailor the Context element for each Host, if needed. A detail that adds flexibility and makes a difference. In practice, I would probably deploy the app, grab the extracted second_world.xml, put it under version control (I know admins don't use that, but I would), make my changes, commit them, and then place a copy in each of the aforementioned directories so it prevents the original from the WAR to be extracted and used. Does that sound like solid operating procedure? :-) Regardless, your webapp will be deployed once for each Host. If you don't want that, just use a single Host, and let it field requests for all of alpha, beta, and gamma. Just to be sure, would I do that by using: Home name=alpha ... Aliasbeta/Alias Aliasgamma/Alias -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat 6.0.20 different instances with diff ips but same port no 80
From: Michael Ludwig [mailto:m...@as-guides.com] Subject: Re: tomcat 6.0.20 different instances with diff ips but same port no 80 I would probably deploy the app, grab the extracted second_world.xml, put it under version control Why not just start out with the Context element under version control? No need to even have it in the .war file if you're always going to override it. Just to be sure, would I do that by using: Home name=alpha ... Aliasbeta/Alias Aliasgamma/Alias The Alias elements aren't needed. If you just have a single Host - which must be the defaultHost for the Engine - all requests go there regardless. It's only when you have multiple Host elements that the name attribute and any Alias elements come into play. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6.0.20 different instances with diff ips but same port no 80
Caldarale, Charles R schrieb: I would probably deploy the app, grab the extracted second_world.xml, put it under version control Why not just start out with the Context element under version control? No need to even have it in the .war file if you're always going to override it. Right. I just imagined being a Tomcat admin receiving an alien WAR without source, but with its particular context.xml - and having to deal with it, and possible successor versions. Home name=alpha ... Aliasbeta/Alias Aliasgamma/Alias The Alias elements aren't needed. If you just have a single Host - which must be the defaultHost for the Engine - all requests go there regardless. It's only when you have multiple Host elements that the name attribute and any Alias elements come into play. That makes sense. Thanks! -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
