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]
