RE: No revolution today
Joseph Chiu [mailto:[EMAIL PROTECTED]] wrote: In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. We are presently employing Joseph's elegant (we force root context only) solution in a production environment running 3.1. As I've mentioned elsewhere, it's critical to us that the load balancing mechanism not be mucked up in future releases; indeed, I'm often very worried that there seems little commitment to maintaining the mod_jserv connector. Everyone loves to say "oh, just use mod_jk" but unless the functionality of the balance sets and routes of mod_jserv are maintained, we can't migrate. $0.02 Andrew -- Andrew Frederick Cowie Director of Operations Upoc, Inc cell: 917-217-4578 office: 212-405-1044 [EMAIL PROTECTED]
Re: No revolution today
In our situation, we plan to use multiple virtual hosts, each with its own root context. That makes the URLs shorter and easier for people to work with. It also lets you more easily move/copy one context to another without having to fix all the links. We use many virtual hosts today in production, however they all share the same root context. To some this might seem counter-intuitive. It actually does make sense if you're using the MVC pattern and you use virtual hosts to define a cluster of alternate views. Just because the "View" is changing doesn't mean the serlvet (controller) isn't identical. We like to avoid loading lots of VM's. In fact, we have base servlets than are extended by host specific servlets for specific views. It also gives you flexibility in the "route" people take to your servers. Hostname A might have hot spares, while hostname B has a cluster of servers behind it. If anybody is interested in the patches, let me know and I'll post them to the list again. Would your patches work in the above scenario as well? If so, I'd love to have them! Is their any reason their not merged into the core 3.2 code? I'd also like to cast my vote for a production quality release and continued development of tomcat 3.x for production use. Definitely want to chime in and agree on this. We're still running 3.1 in production on 8 web servers. It's slow, it doesn't let us do sessions (aforementioned reasons) but hey-- It's stable. -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
How? As far as I can tell it's broken in TC 3.1 / mod_jserv. Can you describe your configuration? On Thu, 9 Nov 2000, [EMAIL PROTECTED] wrote: On Wed, 8 Nov 2000, Nick Bauman wrote: On Thu, 9 Nov 2000, Henri Gomez wrote: It is important that tomcat3 has a design that allows support for future versions of the servlet API, but if tomcat developers don't want to see it happen - so be it. When Servlet2.3 will be final and in wide use, there is nothing that can stop someone from providing the module that supports it ( not necesarily from apache site ). Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at least one or two years. Note that many importants sites still use Apache JServ (API 2.0) and GnuJSP. I for one, would love to see the 3.x codebase's Session API actually work "as advertised" in a web server farm with a rotator box like BigIP. Right now the Session API in tomcat 3.1 /does not work/ across multiple instances of tomcat in a server farm. umm...it does. i use it. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
umm...it does. i use it. -Ys- My understanding is it DOES work for app contexts mapped to a URL like "/myapp" but it does NOT work for the root context. "/" Many of us have webapps that mount to the root context. I spent WAY to much time figuring this out, I'd love to be proven wrong. But the mailing list supports what I'm saying if you search for "load balancing" -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
On Thu, 9 Nov 2000, Nick Bauman wrote: How? As far as I can tell it's broken in TC 3.1 / mod_jserv. Can you describe your configuration? SNIP "as advertised" in a web server farm with a rotator box like BigIP. Right now the Session API in tomcat 3.1 /does not work/ across multiple instances of tomcat in a server farm. umm...it does. i use it. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems __ 4 x /- 3 x -/-- tomcat JVMs Net---Load Balancer apache \-per apachewebserver. (piranha - redhat) \- web servers with mod_jservx 3 i also use : Net---Apache with mod_jserv 30 x tomcat jvms. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
On Thu, 9 Nov 2000, Matthew Dornquast wrote: umm...it does. i use it. -Ys- My understanding is it DOES work for app contexts mapped to a URL like "/myapp" but it does NOT work for the root context. "/" Many of us have webapps that mount to the root context. I spent WAY to much time figuring this out, I'd love to be proven wrong. But the mailing list supports what I'm saying if you search for "load balancing" -Matthew yep. root context bug. reported loong ago. -Ys- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No revolution today
Our site (http://www.spun.com) runs multiple Apache servers with load
balancers ("rotator box like BigIP") that distribute traffic over the Apache
servers. We have a farm of Tomcat servers. The session API's work for us.
The only problem is that Tomcat, as distributed, does not allow load
balancing persistence for the root context. We hacked a way around that
(search the archives if you're interested) - but it's an admitted kludge.
Joseph
-Original Message-
From: Nick Bauman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 08, 2000 8:42 PM
To: [EMAIL PROTECTED]
Subject: Re: No revolution today
On Thu, 9 Nov 2000, Henri Gomez wrote:
It is important that tomcat3 has a design that allows support for
future
versions of the servlet API, but if tomcat developers don't want to see
it
happen - so be it. When Servlet2.3 will be final and in wide use, there
is
nothing that can stop someone from providing the module that supports it
(
not necesarily from apache site ).
Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for
at
least one or two years. Note that many importants sites still use Apache
JServ
(API 2.0) and GnuJSP.
I for one, would love to see the 3.x codebase's Session API actually work
"as advertised" in a web server farm with a rotator box like BigIP. Right
now the Session API in tomcat 3.1 /does not work/ across multiple
instances of tomcat in a server farm.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
reOur site (http://www.spun.com) runs multiple Apache servers with load
balancers ("rotator box like BigIP") that distribute traffic over the Apache
servers. We have a farm of Tomcat servers. The session API's work for us.
The only problem is that Tomcat, as distributed, does not allow load
balancing persistence for the root context. We hacked a way around that
(search the archives if you're interested) - but it's an admitted kludge.
--
Yes, I did see that, and while i admired the hack, it wont work in our
situation. :)
I'd really like to see this very old bug fixed.
If for no other reason, it was stated it would work, and does not.
-Matthew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No revolution today
Matthew, In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. If you want root context and non-root contexts to both coexist, then you'll need to modify my kludge to NOT force the context to the root context. You'll have to test it to see if it works for you (because I haven't). I think Andrew Cowie did the latter (not force the contexts to the root context), but I don't want to speak for him. If you need multiple contexts without the root context, then the existing Tomcat should be perfectly fine. Joseph -Original Message- From: Matthew Dornquast [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2000 2:28 PM To: [EMAIL PROTECTED] Subject: Re: No revolution today Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
In our situation, we plan to use multiple virtual hosts, each with its own root context. That makes the URLs shorter and easier for people to work with. It also lets you more easily move/copy one context to another without having to fix all the links. I've posted patches that make this work for us in the past, along with several other patches for cookie behavior. We're not running this in production yet, but I've had load balancing working as expected (as far as I can tell) with mod_jk and tomcat_32. I don't have the load balancing hardware available for testing, but I've set up DNS round robin, as well as things like killing apache on one host to force it to the other and the sessions being routed properly. If anybody is interested in the patches, let me know and I'll post them to the list again. One fixed root context load balancing (at least for us), cookie deletion, session cookie selection, and one that prevents session cookies other than the valid one from being leaked into a webapp. I'd also like to cast my vote for a production quality release and continued development of tomcat 3.x for production use. Tomcat 4.0 may be elegant, but what I need right now is robust and fast Servlet 2.2/JSP 1.1. Paul Frieden Joseph Chiu wrote: Matthew, In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. If you want root context and non-root contexts to both coexist, then you'll need to modify my kludge to NOT force the context to the root context. You'll have to test it to see if it works for you (because I haven't). I think Andrew Cowie did the latter (not force the contexts to the root context), but I don't want to speak for him. If you need multiple contexts without the root context, then the existing Tomcat should be perfectly fine. Joseph -Original Message- From: Matthew Dornquast [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2000 2:28 PM To: [EMAIL PROTECTED] Subject: Re: No revolution today Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
I'm interested in these patches. Also, I'm interested in the issues with the issues with root contexts (the thread name on tomcat-dev or .java file) Thanks, Kenneth Topp On Thu, 9 Nov 2000, Paul Frieden wrote: In our situation, we plan to use multiple virtual hosts, each with its own root context. That makes the URLs shorter and easier for people to work with. It also lets you more easily move/copy one context to another without having to fix all the links. I've posted patches that make this work for us in the past, along with several other patches for cookie behavior. We're not running this in production yet, but I've had load balancing working as expected (as far as I can tell) with mod_jk and tomcat_32. I don't have the load balancing hardware available for testing, but I've set up DNS round robin, as well as things like killing apache on one host to force it to the other and the sessions being routed properly. If anybody is interested in the patches, let me know and I'll post them to the list again. One fixed root context load balancing (at least for us), cookie deletion, session cookie selection, and one that prevents session cookies other than the valid one from being leaked into a webapp. I'd also like to cast my vote for a production quality release and continued development of tomcat 3.x for production use. Tomcat 4.0 may be elegant, but what I need right now is robust and fast Servlet 2.2/JSP 1.1. Paul Frieden Joseph Chiu wrote: Matthew, In my environment, I wanted to force all contexts to be in the root context. So, my point is -- if you only need the root context (one context only!), my kludge works. If you want root context and non-root contexts to both coexist, then you'll need to modify my kludge to NOT force the context to the root context. You'll have to test it to see if it works for you (because I haven't). I think Andrew Cowie did the latter (not force the contexts to the root context), but I don't want to speak for him. If you need multiple contexts without the root context, then the existing Tomcat should be perfectly fine. Joseph -Original Message- From: Matthew Dornquast [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 09, 2000 2:28 PM To: [EMAIL PROTECTED] Subject: Re: No revolution today Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
No revolution today
Hi, After a lot of thinking, I decided to give up ( at least temporary ) my plans for a tomcat revolution. It was very tempting, but I don't think it's the right thing to do - evolution is still the best way to go :-) It is important that tomcat3 has a design that allows support for future versions of the servlet API, but if tomcat developers don't want to see it happen - so be it. When Servlet2.3 will be final and in wide use, there is nothing that can stop someone from providing the module that supports it ( not necesarily from apache site ). But for now it's important to continue to improve the foundation. My focus will continue to be on Tomcat3.3, in fixing the encoding problems and on improving the performance. We are not yet the best servlet container - so there is still work to do. If you believe that tomcat3 can't be the best container, and a different model is better suited for that - that's perfect, as long as the code you write is reusable everyone will benefit. And I'm sure the users will choose whatever it's better for them, regardless of version numbers. It's open source - and so far the better code has survived regardless of politics. The rules are still there - after a release, the main branch is open for the development of the next release, and as long as we are improving I don't think anyone can stop the evolution. Regarding the other issues ( webdav, etc ) - if the author believes it's not right to provide support for webdav in tomcat3.3 I'll move the implementation in proposals. It's just a webapplication that should work on any container, who needs it can get it without being included in the standard distribution. Regarding the Resource abstraction and the caching code ( that are used in webdav), those will probably go into tomcat3.3 - unless you can vote that better performance is bad for tomcat. Same thing should happen with the HTTP1.1 implementation - it's great code and it shouldn't be tied to a particular container design. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
On Thu, 9 Nov 2000, Henri Gomez wrote: It is important that tomcat3 has a design that allows support for future versions of the servlet API, but if tomcat developers don't want to see it happen - so be it. When Servlet2.3 will be final and in wide use, there is nothing that can stop someone from providing the module that supports it ( not necesarily from apache site ). Many of us could live with a bullet proof TC 3.3 with API 2.2/JSP 1.1 for at least one or two years. Note that many importants sites still use Apache JServ (API 2.0) and GnuJSP. I for one, would love to see the 3.x codebase's Session API actually work "as advertised" in a web server farm with a rotator box like BigIP. Right now the Session API in tomcat 3.1 /does not work/ across multiple instances of tomcat in a server farm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
