no there is only one Apache and also there is no load balance involved. One Apache pointing to 2 Tomcats (2 applications) with different URL.
On Tue, Nov 10, 2015 at 12:18 PM, Björn Raupach <raup...@me.com> wrote: > > > On 10 Nov 2015, at 11:46, Suleman Butt <suleman.b...@gmail.com> wrote: > > > > Thanks, Björn for your reply. > > > > * Load balancing > > is not the case. > > > > * Routing many services within a single website > > The same Apache Web server is serving other applications running on other > > Tomcats > > > > * SSL issues > > The application endpoint URL is HTTPS. > > > > * SLA or corporate policies > > Not sure, but the layout Apache Webserver and Tomcat Application is very > > common here for other applications as well > > > > * Trust > > Not sure what exactly does the term Trust reflect here. > > Well, I met Sysadmins who assign port 80 only to trusted deamons which > defaults to Apache HTTPD. > > > > > > > But on a separate note, if application is not directly accessible > (pointing > > to Tomcat) then what if Apache Web server is down then that could be the > > only point of failure for the entire application or set of applications? > > Don't you think an alternate solution should need to be in place in > > parallel? > > I don’t know your environment. Ask your colleague. Maybe they have 2 Apache > with a load balancer in front. I have seen this in use. > > > > > Thanks. > > > > > > On Tue, Nov 10, 2015 at 11:32 AM, Björn Raupach <raup...@me.com> wrote: > > > >> Hello Suleman, > >> > >>> On 10 Nov 2015, at 11:18, Suleman Butt <suleman.b...@gmail.com> wrote: > >>> > >>> Hi All, > >>> > >>> I have the following configuration. > >>> > >>> Standalone Apache web server is talking to Tomcat AS using AJP > connector. > >>> Both Apache and Tomcat are running on seperate server machines. All my > >>> application components are deployed on the Tomcat AS and Apache is just > >>> used to redirect the user requests to Tomcat. > >>> > >>> Now I have the following requirement, I have been asked by my operation > >>> team member that he needs to " replace Battery and install McAfee" on > the > >>> Apache web server and the activity would require approx. 1 hour. He > also > >>> told me that during this period of time, the entire application would > not > >>> be accessible! > >>> > >>> My question to him was that why can't users access the application by > >>> directly putting the IP of the Tomcat server in the browser during the > >> time > >>> Apache web server is under maintenance? Why can't we access the Tomcat > AS > >>> directly? Once the Apache is up, users can then use the actual URL and > >>> access the application again via Apache web server. > >>> > >>> But the short answer I got from the team member was that *there is no > >>> alternate URL as Tomcat is using AJP connector which cannot be accessed > >> via > >>> browser. * > >>> > >>> So my question is if it really true and there is no alternate way > (quick > >>> solution/workaround) we can avoid the complete outage of the > application? > >> > >> Yes, your colleague is correct. If only the AJP connector is configured > you > >> can’t access Apache Tomcat with your Browser. Your Browser speaks HTTP > >> and not AJP. Thinks would be different if there is an HTTP-Connector > >> configured. > >> > >>> > >>> I am not technically aware of this AJP configuration and constraint, so > >>> that's why I want to make sure if the above condition stated by the > team > >>> member is indeed correct. May be he lacks or unaware of any other > >> alternate. > >> > >> Not judging your colleague here and what is reasoning is. Sysadmins > usually > >> place Tomcat behind an Apache because: > >> > >> * Load balancing > >> * Routing many services within a single website > >> * SSL issues > >> * SLA or corporate policies > >> * Trust > >> > >> We have been running standalone Apache Tomcat since version 6. It is > >> stable and has not caused any troubles in all these years. It is worth > >> trying out. > >> > >> > >>> > >>> So any help/clarification would be really appreciated. > >>> > >>> Many thanks. > >>> > >>> > >>> > >>> -- > >>> Regards Suleman > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > > > -- > > Regards Suleman > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Regards Suleman
