Re: How to receive Session Manager from servlet?

[Mika Goeckel]

I think that is a matter of security. Once it has access to the
SessionManager, your servlet has access to other servlets sessions as well.
That's one reason for the SessionFacade being in place.
The benefit from Tomcat being open source is, that you actually can add a
getSessionManager() to the facade if you can't get away without it.

Mika

- Original Message -
From: "Oto Buchta" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 15, 2002 1:39 PM
Subject: How to receive Session Manager from servlet?


Hi,
I'm revriting the application from the JSDK2.0 to current Tomcat and I found
a very big problem - HttpSessionContext.getIds() is deprecated. It's clear
why, but it brings a critical problem for me.

I've found (in tomcat javadoc), that the
org.apache.catalina.Session.getManager().findSessions() should help me, but
I
cannot find the way how to use the getManager() method, because
request.getSession() returns StandardSessionFacade instead of the
StandardSession, which implements the interface org.apache.catalina.Session.

And my question is this: Could I receive the manager in another way than
rewritting the facade by changing private session to public?

Thanks very much,
--
Oto 'tapik' Buchta

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: preferred method of handling empty form fields

[Mika Goeckel]

Yep,

if you have a one2one mapping between form and bean, you can be sure that
all fields, that have no value will not be touched. As you have reset them
previously, you do something like

<% bean.reset(); %>


So you clear all the fields and let them set afterwards. What is still the
same since you sent the bean's properties in that form to the user will get
into the bean again. What is cleared will remain cleared, because you have
called the reset() method. What has changed will change :-)

If you use a bean for more than one form, you will not be able to do it that
way. It is not really good style to have specialised reset() methods for the
different pages because you couple the bean to the layout of your pages. I
rather would recommend to explicitely set the properties then:
<% if(request.getAttribute("yourProperty")!=null) {
bean.setYourProperty(request.getAttribute("yourProperty");
} else {
bean.setYourProperty(null);
} %>

(Depends on the type your property has. In case of non-string you may have
to do some converting, anyway, to put much code into jsps is not a good
idea)

By the way, do you use a framework? Have a look into jakarta.struts, there
you may find more related stuff.

M.


- Original Message -
From: "Johan Hoogenboezem" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Friday, January 11, 2002 1:43 PM
Subject: RE: preferred method of handling empty form fields


> Hi Mika
> Thanks for your reply. I can see how the reset() method can be useful. It
is
> like the reset type button in html, no? Especially if you re-use the same
> form+bean to edit a lot of records. You don't want to carry over values
from
> the previous record.
> However, I do not see how it will help to figure out which field on the
form
> the user just cleared out (say, by selecting the text with her mouse and
> hitting delete before clicking the submit button) so that the
corresponding
> bean property can also be cleared...
>
> -Original Message-
> From: Mika Goeckel [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 11, 2002 2:32 PM
> To: Tomcat Developers List
> Subject: Re: preferred method of handling empty form fields
>
>
> Hi Johan,
>
> I always create a reset() method within beans to circumvent this problem.
It
> clears all fields that I don't want to hold any value during form
> processing.
>
> Mika
>
> - Original Message -
> From: "Johan Hoogenboezem" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 11, 2002 1:02 PM
> Subject: preferred method of handling empty form fields
>
>
> > Hi
> > I use tomcat 3.2 on various platforms.
> >
> > My problem is this: when modifying a bean's properties through a jsp
form,
> I
> > would like a property to be cleared if the corresponding form field is
> > cleared. The introspect(...) method in the JspRuntimeLibrary does not do
> > this for me.
> >
> > I searched the archives and found that according to the spec, if a
request
> > parameter has no value, then the corresponding bean property is not to
be
> > modified (see
http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html).
> Oh
> > well.
> >
> > That still leaves me the problem of handling empty fields. I could
> > 1) Go through the list of request parameters myself and clear the
> > corresponding bean properties if parameters have no value. This feels
like
> > duplicating some of what the introspectHelper(...) method does.
> > 2) Use javascript to record all empty fields to a hidden field at submit
> > time. This is rather cumbersome and requires a little extra code in the
> form
> > bean.
> >
> > I've used both but neither is very satisfying.
> >
> > So, to summarize, is there a preferred or recommended way of doing this
> that
> > anybody knows of?
> >
> > Thanks
> > Johan Hoogenboezem
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: preferred method of handling empty form fields

[Mika Goeckel]

Hi Johan,

I always create a reset() method within beans to circumvent this problem. It
clears all fields that I don't want to hold any value during form
processing.

Mika

- Original Message -
From: "Johan Hoogenboezem" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 11, 2002 1:02 PM
Subject: preferred method of handling empty form fields


> Hi
> I use tomcat 3.2 on various platforms.
>
> My problem is this: when modifying a bean's properties through a jsp form,
I
> would like a property to be cleared if the corresponding form field is
> cleared. The introspect(...) method in the JspRuntimeLibrary does not do
> this for me.
>
> I searched the archives and found that according to the spec, if a request
> parameter has no value, then the corresponding bean property is not to be
> modified (see http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html).
Oh
> well.
>
> That still leaves me the problem of handling empty fields. I could
> 1) Go through the list of request parameters myself and clear the
> corresponding bean properties if parameters have no value. This feels like
> duplicating some of what the introspectHelper(...) method does.
> 2) Use javascript to record all empty fields to a hidden field at submit
> time. This is rather cumbersome and requires a little extra code in the
form
> bean.
>
> I've used both but neither is very satisfying.
>
> So, to summarize, is there a preferred or recommended way of doing this
that
> anybody knows of?
>
> Thanks
> Johan Hoogenboezem
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: load balancing - integration thoughts

[Mika Goeckel]

Hi Tom, hi Craig!

Another approach would be to extend the event model that is used for Session
(Servlet Spec SRV.10.1/SRV15.1.13) to fire events when a request is
completed..
Craig, would it be compliant with the spec to add another subclass of
SessionEvent (Maybe SessionRequestEvent)?

Then you could register your manager with newly created sessions as a
SessionListener.

Mika

- Original Message -
From: "Tom Drake" <[EMAIL PROTECTED]>
To: "Mika Goeckel" <[EMAIL PROTECTED]>
Cc: "Craig McClanahan" <[EMAIL PROTECTED]>
Sent: Tuesday, December 18, 2001 8:50 PM
Subject: load balancing - integration thoughts


> Mika and/or Craig:
>
> After having looked around the code, here's my thoughts
> about how to implement 'end-of-request' notification. Because
> we need post session updates to the 'other' repositories,
> and 'unlock' the session at the end of each Http request.
>
> Can you review and comment? Being new to Tomcat, I'd
> like some confirmation that I'm on the right track, or some
> gentle guidance.
>
> o.a.c.Manager.java
> - add new method
> public void completeRequest(String sessionId);
>
> o.a.c.session.ManagerBase.java
> - add new method
> public void completeRequest(String sessionId) {
> // noop - non-distributed sessions don't care.
> }
>
> o.a.c.Request.java
> - add new method
> public void completeRequest();
>
> o.a.c.connector.ResponseBase.java
> - modify 'finishResponse()' by adding the following code
>getRequest().completeRequest();
>
> o.a.c.connector.RequestBase.java
> - add new method
> public void completeRequest() {
> if (session != null) {
> manager.completeRequest(session.getId());
> }
> }
>
> o.a.c.session.RepositoryManager - new class that extends
> StandardManager.java.
>
> public void completeRequest(String sessionId) {
> // deal with updating the remote repositories here
> }
>
> There's lots of other code in RepositoryManager, I just wanted to focus
> on the end-of-request notification bits.
>
>
> Regards,
>
> Tom Drake
> President, software/etc inc.
> Email: [EMAIL PROTECTED]
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: server.xml DTD/Schema

[Mika Goeckel]

A first cut of dtd and schema are reviewable under:

http://www.mikagoeckel.de/tomcat/server.html,

http://www.mikagoeckel.de/tomcat/server.xsd
http://www.mikagoeckel.de/tomcat/server.dtd

I've thrown all possible attributes for the different classes into the tag,
so this is nothing more than to validate structure of tags.
Remember this is a first cut, so validate your server.xml against it and
report flaws to me, I'm happy to continue refining it.

Comments welcome.

P.S.: Who is maintaining the documentation on jakarta.apache.org/tomcat
I think the graphics from this work could add some clarity to it.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: server.xml DTD/Schema

[Mika Goeckel]

Craig, yes, that's exactly the problem. Valve is another prominent case
where the attribute-checking is not possible.

One solution, but I confess that I would not recommend it, is to distinguish
between the different types, i.e. change  to
,, etc. That would
certainly make the server.xml validatable, but create the burden of changing
the xsd/dtd every times a user creates her own Valve/Logger/Realm etc.

Could xslt be a solution to check the required attributes if the dtd/schema
uses union? Maybe that is to much effort because anyway if a required
attribute is not present, the digester would moan.

Mika

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2001 4:09 AM
Subject: Re: server.xml DTD/Schema


> One thing to remember is that it is not technically possible to write a
> DTD for server.xml that covers all possible cases (and I suspect that's
> true for Schema as well).  Consider the following cases:
>
> * Elements like  and  let you define which implementation
>   class you want, from the set of choices included with Tomcat.  The set
>   of attributes that are valid depends on which implementation class you
>   choose -- and there is no way to make that distinction in a DTD.  The
>   best you could do is list the union of all possible attributes -- but
>   that is not semantically valid for any single implementation.
>
> * Even more generally, Tomcat users are free to install their own
>   implementations of Tomcat classes, and there's no way your general
>   purpose DTD would know which attributes are valid.
>
> Craig McClanahan
>
>
>
> On Fri, 30 Nov 2001, Mika Goeckel wrote:
>
> > Date: Fri, 30 Nov 2001 01:01:46 +0100
> > From: Mika Goeckel <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: server.xml DTD/Schema
> >
> > Hi,
> >
> > I've built a first version of a DTD/Schema for server.xml and would ask
if
> > someone would like to review it?
> >
> > I would prefer the Schema, because it allows more checking, but I
haven't
> > seen a parser which checks against schemes, so I created a DTD from it
as
> > well.
> >
> > As this is quite a bunch of lines, please hands up who wants to receive
it.
> >
> > Cheers, Mika
> >
> > P.S.: The initial cut is from the docu, I plan to go through the source
> > tomorrow to recheck.
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: server.xml DTD/Schema

[Mika Goeckel]

H

I've been too fast with this announcement, I need some help.

I've got a problem with Connector (and other cases). I miss a concept like
interface in XML Schema.
A Connector might be of different types:
HTTP/1.1 Connector
HTTP/1.1 Connector with SSL support
Warp Connector

and others might come in the future.

All of these three connectors have different attributes, but the XML
colloquial definition name all of them simply .
There is no way to check for 'required' if we simply just throw all possible
attributes in the dtd/schema definition, because some are mutual exclusive.

Does anybody have a clue how to solve that? My suggestion would be to clean
up the XML and define proper elements for different purposes which might
result in some coding work...

Mika

- Original Message -
From: "Mika Goeckel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 30, 2001 1:01 AM
Subject: server.xml DTD/Schema


> Hi,
>
> I've built a first version of a DTD/Schema for server.xml and would ask if
> someone would like to review it?
>
> I would prefer the Schema, because it allows more checking, but I haven't
> seen a parser which checks against schemes, so I created a DTD from it as
> well.
>
> As this is quite a bunch of lines, please hands up who wants to receive
it.
>
> Cheers, Mika
>
> P.S.: The initial cut is from the docu, I plan to go through the source
> tomorrow to recheck.
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

server.xml DTD/Schema

[Mika Goeckel]

Hi,

I've built a first version of a DTD/Schema for server.xml and would ask if
someone would like to review it?

I would prefer the Schema, because it allows more checking, but I haven't
seen a parser which checks against schemes, so I created a DTD from it as
well.

As this is quite a bunch of lines, please hands up who wants to receive it.

Cheers, Mika

P.S.: The initial cut is from the docu, I plan to go through the source
tomorrow to recheck.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Disable Refresh Function in IE

[Mika Goeckel]

Tom,

there may be some application, where such behavior is expensive, i.e. hit
the 'acknowledge credit card charge' button twice.
The worker servlet would have the requests first, so it has to intercept the
second. As the out stream of the first is gone in the view of the browser,
you would need clever logic. I.e. rollback the transaction of the first and
execute the second as if nothing special happened.

M.
^X^S
- Original Message -
From: "Tomas Rokicki" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 28, 2001 8:32 PM
Subject: RE: Disable Refresh Function in IE


> You can't really avoid refresh.
>
> Consider that people can double-click on a submit button or
> link, quite inadverdantly, and your server sees it as two
> submissions but you only get the second response.
>
> Other than the timing, there is very little to distinguish this
> >from hitting the refresh button.
>
> If the server refuses to serve refresh requests, well, you've
> just broken anyone with a slow finger on the mouse.
>
> (And yes, some people still double-click links intentionally
> because you double-click to launch on Windows and why should
> the Web be any different?  True these people are typically
> moms and pops, but everyone's got them, right?  Parents, that
> is?)
>
> -tom
>
> -Original Message-
> From: Denis Balazuc [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 28, 2001 11:28 AM
> To: Tomcat Developers List
> Subject: Re: Disable Refresh Function in IE
>
>
> No, there's no way to disable any of the browser's buttons such as
Refresh,
> Back or Forward
>
> The only way to prevent a refresh is to maintain some flag when you serve
> requests, but even this is hardly feasible.
> I'd love to hear about a clean solution on that topicWe need to avoid
> people from refreshing pages too
>
> - Original Message -
> From: "Bala Nemani" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, November 28, 2001 12:54 PM
> Subject: Disable Refresh Function in IE
>
>
> > Hi:
> >
> > Is there a way to disable REFRESH functionality. I.e. not just
> > hiding the Refresh button but disable the refresh functionality it self
> (F5
> > function key also).
> >
> > Thanks
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [TC4] How to know when tomcat is properly shut down?

[Mika Goeckel]

Hi,

on a unix system, you could do something like

if ps -efwww | grep "org.apache.catalina.startup.Bootstrap" | grep -vc
"grep" >/dev/null;
then echo "yes";
else echo "no";
fi

the second grep is because grep might find it's own command line otherwise.

hope that helps.

Cheers, Mika

- Original Message -
From: "Endre Stølsvik" <[EMAIL PROTECTED]>
To: "Tomcat developer list" <[EMAIL PROTECTED]>
Sent: Wednesday, November 28, 2001 6:53 PM
Subject: [TC4] How to know when tomcat is properly shut down?


> This did not get answered the first time, so I'll try again!! Better luck
> this time? Please??
>
> --
> Mvh,
> Endre
>
> -- Forwarded message --
> Date: Wed, 21 Nov 2001 09:10:54 +0100 (MET)
> From: Endre Stølsvik <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat developer list <[EMAIL PROTECTED]>
> Subject: [TC4] How to know when tomcat is properly shut down? (fwd)
>
> Since nobody answered on tomcat-user, I'll just forward this one here
> (since I think it actually belongs here in the first place..)
>
> -- Forwarded message --
> Date: Tue, 20 Nov 2001 18:14:20 +0100 (MET)
> From: Endre Stølsvik <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat user list <[EMAIL PROTECTED]>
> Subject: [TC4] How to know when tomcat is properly shut down?
>
> The catalina.sh and related scripts all start the Bootstrap.java class and
> asks it to shut down Catalina.
>
> This script, if successful in connecting to the shutdown port of Catalina,
> returns immediately. This whether or not there is 8953289527 pending
> database commits or whatever that has to be done before things actually
> are properly shut down.
>
> This is highly undesirable, and I would love if it were possible to shut
> down catalina and then chill untill it actually has shut down.
>
> This is especially important when shutting down the entire server, as the
> database shutdown might be the next in line, in which case everything
> breaks..
>
> Of course, it would also be very nice if one could know if Catalina has
> properly come up. It could for example write a "boolean file" when the
> server has initialized all webapps, and then delete the same file right
> before the main method of Catalina exits on shutdown. Or one could use
> Bootstrap with argument -waitForUp or something..
> ---
>
> And yes, Henri's init.d scripts also just fake this, waiting in just 2
> seconds, which is too short time, and therefore the "restart" option of
> the init.d script is flawed. The shutdown part of it doesn't wait at all,
> so you might end up shutting the server physically down (read as: killing
> all the java threads w/o cleaning up) before tomcat has finished shutting
> down.
>
> Mvh,
> Endre
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Disable Refresh Function in IE

[Mika Goeckel]

Hi,

the way to do that, is to create a rigid state model of your application and
use a centralized worker servlet (hide all other pages/jsps/servlets from
the user).
Struts gives the framwork for that.

Mika

- Original Message -
From: "Denis Balazuc" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 28, 2001 8:27 PM
Subject: Re: Disable Refresh Function in IE


> No, there's no way to disable any of the browser's buttons such as
Refresh,
> Back or Forward
>
> The only way to prevent a refresh is to maintain some flag when you serve
> requests, but even this is hardly feasible.
> I'd love to hear about a clean solution on that topicWe need to avoid
> people from refreshing pages too
>
> - Original Message -
> From: "Bala Nemani" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, November 28, 2001 12:54 PM
> Subject: Disable Refresh Function in IE
>
>
> > Hi:
> >
> > Is there a way to disable REFRESH functionality. I.e. not just
> > hiding the Refresh button but disable the refresh functionality it self
> (F5
> > function key also).
> >
> > Thanks
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: 4.0.1 ClassLoader breaks singletons on webapp reload.

[Mika Goeckel]

??

Don't understand that joke. EJB's are usually not singletons. An application
server may decide how many instances it creates in the case of stateless
session beans, so he may choose to only create one, but most commercial
servers (weblogic, websphere) adjust the number of beans according to the
traffic (concurrent sessions).

Could you clarify that?

Mika

- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: "tomcat-dev" <[EMAIL PROTECTED]>
Sent: Monday, November 26, 2001 10:04 PM
Subject: Re: 4.0.1 ClassLoader breaks singletons on webapp reload.


> Yea, those are called EJB's. :-)
>
> EJB - The glorified Singleton.
>
> -jon
>
>
> on 11/26/01 6:05 AM, "Mika Goeckel" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > could you get around the singleton problem by placing the singleton
object's
> > class outside the classloader which get busted when reloading the
changed
> > servlets/jsps? You could move it up to the 'shared' or even 'common'
> > classspace. Do I understand it right, that these class loaders are not
being
> > destroyed when TC is running? I'm not so deep into that matter, maybe I
> > completely misunderstand something...
> >
> > Mika
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: 4.0.1 ClassLoader breaks singletons on webapp reload.

[Mika Goeckel]

Hi,

could you get around the singleton problem by placing the singleton object's
class outside the classloader which get busted when reloading the changed
servlets/jsps? You could move it up to the 'shared' or even 'common'
classspace. Do I understand it right, that these class loaders are not being
destroyed when TC is running? I'm not so deep into that matter, maybe I
completely misunderstand something...

Mika

- Original Message -
From: "Kevin A. Burton" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, November 26, 2001 8:52 AM
Subject: Re: 4.0.1 ClassLoader breaks singletons on webapp reload.


> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jon Stevens <[EMAIL PROTECTED]> writes:
>
> > on 11/25/01 9:57 PM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
> >
> > > Of course, there's a reason for this, as a selective reloading would
be a
> > > very complex thing to do.
> > >
> > > Remy
> >
> > More like damn near impossible. Once the previous classloader has been
> > trashed, all objects which were created within it would then become
invalid.
> >
> > Kevin, the right thing to do is to setup something like Turbine's
Services
> > which have a shutdown process which can be invoked when the servlets
destroy()
> > method is called in order to shutdown the singletons.
>
> Ah.  Interesting.  This technique would work but would require the
'restart'
> (there's that word again) the whole application.
>
> ... at this point I think it might make sense just to restart Tomcat as
shutting
> down and restarting the app would take just as long as a full restart.
>
> It is a shame because there is a lot of potential in just reloading that
one
> class.
>
> > Sadly, I have to admit that the Turbine Services framework shutdown code
is
> > currently broken and has been for some time now...it needs to be
re-written...
>
> Are you saying that the theory is broken or just Turbine's impl?
>
> Kevin
>
> - --
> Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED] )
>  Location - San Francisco, CA, Cell - 415.595.9965
> Jabber - [EMAIL PROTECTED],  Web - http://relativity.yi.org/
>
> Windows 95 - A 32 bit extension to a 16 bit shell for a 8 bit operating
system
> designed for 4 bit computers by a 2 bit company that can't stand 1 bit of
> competition.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt
>
> iD8DBQE8AfRrAwM6xb2dfE0RAuB1AJ0aAkQbAp5lkmnUMOVJ0BG0Ipf6YwCghsRo
> +avbgG+W5aqsXELI1RKaPcI=
> =Aq5S
> -END PGP SIGNATURE-
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Distributed Session Management

[Mika Goeckel]

Tom,

from my (personal?!) philosophy, tests should be with the tested targets. My
experience tells me that tests get out of focus if they are in a separate
tree.
Now when you are going to start hacking, is your approach creating use
cases, sequence diagrams etc. before, or something like class responsibility
cards?

M.

- Original Message -
From: "Tom Drake" <[EMAIL PROTECTED]>
To: "Tomcat Dev List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 8:39 PM
Subject: Distributed Session Management


> Tomcat Developers:
>
> I'm going to try to synthesize the results of yesterdays
> discussion on Distributed Session Management into some
> working code. From what I can tell, there will be some
> changes and new objects in the org.apache.session
> package, and possibly some new objects in the
> org.apache.cluster package.
>
> I should have something to share in the next couple of
> days. I'll be creating JUnit tests as I write this code. Is there
> a standard place to put JUnit tests, or can I simply place
> them in the same package as the classes being tested?
>
> Regards,
>
> Tom Drake
> Email: [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

Costin,

that point of view is really interesting. What about separating the
distribution part from the integration part of a integrated solution.
That would user's give the option to use the "transparent session
replication" or to use "explicit object replication services".
The former would ease their live with the drawback of missing transaction
support, the latter would give the app-developer all control over it.

M.

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 6:27 PM
Subject: Re: Tomcat: Distributed Session Management revisited


> To clarify: creating a Distributed Session Manager is a good idea, and
> something that would be great for users.
>
> My problem is with designing it at container-level, as an implementation
> of the servlet session API.
>
> Having all objects in a session distributed and no control or feedback is
> not good.
>
> You could have a DSMServlet that would have some init parameters in
> web.xml. There you can specify what classes/interfaces you want
> 'distributed', or even what attributes ( by name ).
>
> Then you can use the existing listeners and notifications to detect when
> those objects are saved in the session and do the distribution.
>
> You could also define a simple API allowing the user to control this - for
> example and update() method to be called after the user changes an object.
>
> What's different here is that the behavior of servlet sessions doesn't
> change - most objects can still be stored without an overhead. The user
> gets to choose what objects to persist/distribute and he has control over
> the process. And this will work in _any_ container, so the user can assume
> the objects he marks as persistent/distributable will be this way on any
> container ( you can't force people to switch to a different container to
> use your webapp )
>
> You can also define specialized interfaces to be implemented by the
> objects that will be persisted/distributed.
>
> All of this can be done with only standard 2.3 support. A container may
> provide aditional hooks ( valves, interceptors, etc) of course.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 12:26 AM
Subject: Re: Tomcat: Distributed Session Management revisited


> On Tue, 13 Nov 2001, Mika Goeckel wrote:
>
> > I completely agree, that the API lacks proactive support for things in
the
> > background that may fail.
> > But given the fact, that we support a reference implementation which has
> > managed to provide really professional services to users (other ref
> > implementations are just for demonstration, nobody would use them in
> > production) and there are (commercial) solutions, that provide session
> > fail-over in the limitations of this API, we **must** try to provide a
>
> Well, the cool thing about open source is that we _don't_ need to
> implement all the bloat that commercial solution have.

Costin, I don't disagree with your opinion. We don't need to, because we
work on a voluntary base.
But don't you think that having the option to provide better or at least
equally professional solutions is a good motivation?

> > solution. The API does not specify, how often the container may try to
> > provide that service or what means it utilizes to do that. Nothing is
100%
> > and I think it is better to live with the uncertaincy we discuss here
than
> > with the more likely problem that an instance fails and there is no
> > potential replacement.
>
> I think it's better to live with the certaincy that everything can (
> and will ) fail and tomcat can't change this.
>
> The alternative is to give users the impression the data he puts in a
> session will be safe - and he may rely on that instead of using a
> transaction and a real API.
>
> Databases, EJB, etc are complex - but there's a reason to that. Well,
> we could argue about how much compexity is actually needed, but
> one thing is certain ( I hope ) - get/setAttribute is not enough, if you
> want data integrity you must use a different API ( in particular
> transactions ).
>
>
> > Byte-comparison is not the worst solution. If we think about
differential
> > updates, byte comparison is a good candiate for that and surplus one
that
> > promises good performance.
>
> Byte compare every 5 seconds every object in session ? Let's say you just
> displayed the confirmation and charged the credit card, but the machine
crashed just
> before you sent the order. ( or reverse - you sent it but didn't charged
> the credit card ). This should happen in below 5 seconds.

Yep, but a single stand-alone instance is not invulnerable to that scenario.
In fact a thoroughly designed cluster gives better chances.

> > If the user wants to place things in a session that she does not need to
be
> > replicated, she has the option to declare them transient and write a
getter
> > that checks if the Attribute is present, otherwise reconstructs it (in
the
> > case of a picture, reloads it from disk). The user has the choice to
design
> > for performance or ease. We only need to document the options.
>
> So the user should change all his objects to implement some arbitrary
> pattern just to fit this into our solution ?
>
> What if the object is not user defined ( like most are ) ? Well, we
> have to create  wrappers for each objects you store in a session. Try to
> explain this on tomcat-user ( or tomcat-dev ) ...

If the only alternatice is to use a professional EJB server, he would need
to change them as well.
I don't say he has to mark these values transient, it's only an option. And
transient is not an arbitrary option, it's core java since JLS1.1 (1998).

Sessions have always been somewhat fragile, but as the container is free to
use transactions when the session is passed to another instance, at least
that can be made secure enough. So the guarantee to the user of the
container would not be made weaker. If the transaction fails, the session
stays with the JVM where it originally was. The fail-over functionality
would not be possible, but the situation to the app-developer would stay
stable.

I think that the documentation must clearly communicate to app-developers
the risks and shortfalls of a distributed application and then let them
choose by themselves what best meets their requirements.

Mika


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

- Original Message -
From: "Paul Speed" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 11:30 PM
Subject: Re: Tomcat: Distributed Session Management revisited


>
>
> Tom Drake wrote:
> >
> > - Original Message -
> > From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom
Drake"
> > <[EMAIL PROTECTED]>
> > Sent: Tuesday, November 13, 2001 1:25 PM
> > Subject: Re: Tomcat: Distributed Session Management revisited
> >
> > ... stuff deleted ...
> >
> > | > | It would be possible to do this for the HttpSession methods
> > | > | themselves (the container would know what's going on), but what do
you
> > do
> > | > | about session attributes?
> > | > |
> > | > |   HttpSession session = request.getSession();
> > | > |   MyObject mo = (MyObject) session.getAttribute("foo");
> > | > |   mo.setName("bar");
> > | >
> > | > I believe that,  in this case, it is incumbent upon the application
to
> > call
> > | >
> > | > session.setAttribute("foo", mo);
> > | >
> > |
> > | This violates the principle that the application programming model
should
> > | not change, but it's certainly feasible to say "if you want load
balancing
> > | to work on this container, you have to call HttpSession.setAttribute()
> > | whenever you modify an attribute's properties".
> > |
> > | By itself, though, this doesn't provide any support for locking
against
> > | simultaneous updates (i.e. what you do in "synchronized" blocks in a
> > | single VM).
> > |
> > | It's a little funny funny ... by the time we invent API to solve all
these
> > | problems, you've just defined a pretty fair chunk of the functionality
of
> > | EJBs ...
> > |
> >
> > Locking issues aside, this presents a fair problem for the servlet
> > container. How to know if any session attribute was modified per
> > your example.
>
> I'm not saying this is necessarily a "good" idea, but you can byte
> compare the resulting session serialization to see if the session
> objects have changed.  All you have to do is keep a local copy of
> the original session during the request.  Not very pretty, but
> is a solution that wasn't discussed.
>
> I tend to agree with Costin that the session API isn't well suited
> for failover/distribution.  I don't think it's impossible though.
> Plus, if you decide to develop an API separate from the session...
> it really starts to look like EJB.

I completely agree, that the API lacks proactive support for things in the
background that may fail.
But given the fact, that we support a reference implementation which has
managed to provide really professional services to users (other ref
implementations are just for demonstration, nobody would use them in
production) and there are (commercial) solutions, that provide session
fail-over in the limitations of this API, we **must** try to provide a
solution. The API does not specify, how often the container may try to
provide that service or what means it utilizes to do that. Nothing is 100%
and I think it is better to live with the uncertaincy we discuss here than
with the more likely problem that an instance fails and there is no
potential replacement.

Byte-comparison is not the worst solution. If we think about differential
updates, byte comparison is a good candiate for that and surplus one that
promises good performance.

If the user wants to place things in a session that she does not need to be
replicated, she has the option to declare them transient and write a getter
that checks if the Attribute is present, otherwise reconstructs it (in the
case of a picture, reloads it from disk). The user has the choice to design
for performance or ease. We only need to document the options.

Mik
:wq


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

Cool, sounds like having a primary owner and front-end redirection to it
solves that without lock distribution.
Means that an owner can't allow another TC to take over a session whilst
processing a request, but as he knows when he's finished, that's easy.

M.

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 9:31 PM
Subject: Re: Tomcat: Distributed Session Management revisited


>
>
> On Tue, 13 Nov 2001, Mika Goeckel wrote:
>
> > Date: Tue, 13 Nov 2001 21:19:35 +0100
> > From: Mika Goeckel <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Tomcat: Distributed Session Management revisited
> >
> > Hi Craig,
> >
> > am I understanding right, that "handling" in this context means the part
of
> > execution when the servlet's service routine is called? Would the
container
> > be allowed to fetch a session after the request has reached it but
before
> > the servlet's code is called?
> >
>
> It is not legal that the following scenario occur:
> * Two simultaneous requests for the same session.
> * Your container processes these requests in different JVMs.
>
> Details of when the restriction starts are basically dependent on the
> container's implementation -- but it's the result that must be obeyed.
>
> The reason for the restriction is pretty obvious when you think about
> this series of events (in chronological order):
> * Request 1 sent to server A
> * Request 2 sent to server B
> * Request 1 grabs session and calls session.setAttribute("foo", bar).
> * Request 2 grabs session and calls session.getAttribute("foo").
>
> On a server that properly implements the restriction, request 2 will
> always see the "foo" attribute, just as would occur in a non-distributed
> environment (which, by definition, would be processing both requests in
> the same JVM on different threads).  Thus, from the application
> developer's perspective, you don't have to worry about the possibility
> that session attributes might be getting accessed or modified on multiple
> JVMs at the same time.
>
> It also means that the application can implement thread-safety locking
> with "synchronized" and have it work correctly on a single JVM or multiple
> JVM container.  This isn't possible if the same session attribute can be
> accessed from multiple JVMs simultaneously.
>
> > Is it theological to ask if a proxy session object that would call the
> > methods of a session object in another JVM would violate that
requirement?
> > >From the application developers point of view he would not see a
> > difference...
> >
>
> It would be possible to do this for the HttpSession methods
> themselves (the container would know what's going on), but what do you do
> about session attributes?
>
>   HttpSession session = request.getSession();
>   MyObject mo = (MyObject) session.getAttribute("foo");
>   mo.setName("bar");
>
> This cannot be done transparently unless MyObject class is actually an RMI
> or Corba reference, and even then the app would have to deal with the
> possibility of exceptions caused by the container's activities, not it's
> own.
>
> The whole idea is that the programming model for the application developer
> doesn't change in a distributable application.  The fact that it makes
> life tougher on the container developer is what makes this particular
> functionality quite interesting to implement :-).
>
> > Mika
> > :wq
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

> Can't help you on that... But, if we "customize" the lookup tables
> abstracting it from JNDI, we could write also some C code for the
web-server
> modules that could participate in our session pooling group, and direct
> requests where they should be, two pigeons with a single shot :)

Something in the response like "and by the way, that are my replica holders"
? Or a dedicated communication protocol?
The former is easier, but what if you have more than one frontend? So they
would need to communicate as well

M.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

Hi Craig,

am I understanding right, that "handling" in this context means the part of
execution when the servlet's service routine is called? Would the container
be allowed to fetch a session after the request has reached it but before
the servlet's code is called?

Is it theological to ask if a proxy session object that would call the
methods of a session object in another JVM would violate that requirement?
>From the application developers point of view he would not see a
difference...

Mika
:wq

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
<[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 8:41 PM
Subject: Re: Tomcat: Distributed Session Management revisited


>
>
> On Tue, 13 Nov 2001, Tom Drake wrote:
>
> > I want a distributed session store, where all sessions are known (or
> > are knowable) by all members of the cluster, with a built-in
> > fail-over mechanism?
>
> As you guys discuss this, don't forget a very important requirement in the
> servlet specification with regards to distributable applications:
>
> [Servlet Spec 2.3, Section 7.7.2]  "Within an application
> marked as distributable, all requests that are part of a
> session must be handled by one virtual machine at a time."
>
> In effect, this means that a session can be migrated to a different server
> only "between" requests.  On a failure of the server currently handling
> the session, you could migrate it to a different server, but this
> operation must be atomic.
>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

:-)


> | On 13/11/2001 04:38 pm, "Mika Goeckel" <[EMAIL PROTECTED]> wrote:
> |
> | > SNMP, ah ja. I've got no knowledge at all 'bout that, so fight with
some
> | > other lobbyists :-)
> |
> | Same here...
>
> Didn't mean to take a left turn. Sorry I mentioned it.

No need to mention, nobody felt offended. I was just joking :-)

>
> |
> | > SessionManager/ServletContainer dualism:
> | > If we don't create a separate SessionManager residing in it's own JVM,
> but
> | > make it an integral capability of TC, we have the following benefits:
> | > - we save one copy:
> | > When a new session is created and we have a separate network of SMs,
it
> | > needs to be copied to at least two SMs, if we have it in TC, it only
> needs
> | > to be copied to one other TC. (If we aim single redundance)
> |
> | Indeed it would save bandwidth...
>
> I want a distributed session store, where all sessions are known (or
> are knowable) by all members of the cluster, with a built-in
> fail-over mechanism?
>
> I want to be able to scale my web server by simply adding
> more standalone Tomcats and possibly session managers.
> I want to be able to use a brand-x HTTP load-balancer that
> redirects web-traffic on a request-by-request basis to the tomcat
> webserver that it thinks can best handle the request. I also want
> to be able to bring down individual Tomcats without destroying
> any user sessions.
>
> Apache's 'smart' approach (that remembers which JSESSIONID's
> are hosted by which Tomcat Servers) doesn't let me bring down
> individual Tomcat servers without losing sessions. This means
> that Tomcat servers are simply not 'hot-swappable' in this configuration.
>
> ASFAICT, minimal redundance is all that is required. There's simply
> no need to keep a gratuitous number of session copies around.
>
> |
> | > - if one TC is the owner and the other the escrow, the owner never
needs
> to
> | > ask if the session is uptodate or invalid, and it can't get stale. The
> | > replication of changes can be done after the request, so no time
burden
> | > within the request itself.
> | > If the escrow want's to use the session, it only needs to inform the
> owner
> | > and they change roles (or if possible the escrow passes the request
back
> to
> | > the owner)
> | > Frequently all servers ping their known escrows and owners to ensure
> they're
> | > still present.
> |
> | The only problem I could see with that is synchronization of accesses
from
> | different points, but I believe that is a solvable problem...
> |
> | > - deserialisation should not be a problem, because in that ClassLoader
> | > Context, the user-session objects are known. (correct me if I'm wrong
> here)
> |
> | Nope, you're right on that.
>
> This is only an issue in the event that the Session Manager is a seperate
> entity.
>
> |
> | > AutoConf what about JNDI to register cluster nodes? It is around
> anyway.
> | > In that case an upcoming TC would just search the JNDI service for
> | > registered nodes with his own ClusterName, and register itself with
it.
> | > Getting back a NamingEnumeration, it could decide itself, which of the
> | > others to link with.
> |
> | One thing that can be done with my approach of multicasting is automatic
> | load balancing... To any request of "who can hold this session", each
> | manager can return a load index, and the decision on where the session
> | should be stored primarily and in replica should be based on that. Using
> | JNDI that can be done, but I don't want to end up in a situation where a
> | single host holds 80% of the sessions while the others are free... If
the
> | managers could update their JNDI registrations with a "load" factor
every
> X
> | seconds, that would be acceptable...
> |
>
> One thing to remember here is that the number of 'clients'
> in our discussion is always fixed - it is the number of Tomcat
> web servers in the 'cluster'. The load of the session managers
> is a direct function of the load on it's clients. Hopefully, the load
> balancer on the front end (either Apache round-robin, or some
> firmware solution) is doing a 'reasonable' job of spreading the
> load across web servers / tomcats. Therefore, as long as the
> number of Tomcats served by each Session manager is
> approximately the same, we can deduce that the load placed
> on the session managers will ALSO be reasonably well balanced.
> If my deduction is correct, then there should be no need for
&g

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

SNMP, ah ja. I've got no knowledge at all 'bout that, so fight with some
other lobbyists :-)

SessionManager/ServletContainer dualism:
If we don't create a separate SessionManager residing in it's own JVM, but
make it an integral capability of TC, we have the following benefits:
- we save one copy:
When a new session is created and we have a separate network of SMs, it
needs to be copied to at least two SMs, if we have it in TC, it only needs
to be copied to one other TC. (If we aim single redundance)
- if one TC is the owner and the other the escrow, the owner never needs to
ask if the session is uptodate or invalid, and it can't get stale. The
replication of changes can be done after the request, so no time burden
within the request itself.
If the escrow want's to use the session, it only needs to inform the owner
and they change roles (or if possible the escrow passes the request back to
the owner)
Frequently all servers ping their known escrows and owners to ensure they're
still present.
- deserialisation should not be a problem, because in that ClassLoader
Context, the user-session objects are known. (correct me if I'm wrong here)

AutoConf what about JNDI to register cluster nodes? It is around anyway.
In that case an upcoming TC would just search the JNDI service for
registered nodes with his own ClusterName, and register itself with it.
Getting back a NamingEnumeration, it could decide itself, which of the
others to link with.

Mika

- Original Message -
From: "Tom Drake" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 4:47 PM
Subject: Re: Tomcat: Distributed Session Management revisited


> Pier, Mikal:
>
> I agree, I think the juices are flowing. See below
>
> Tom
> - Original Message -
> From: "Mika Goeckel" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, November 13, 2001 1:37 AM
> Subject: Re: Tomcat: Distributed Session Management revisited
>
>
> | Pier, Tom,
> |
> | cool, the discussion is starting to become interesting. :-)
> |
> | comments below:
> |
> | - Original Message -
> | From: "Pier Fumagalli" <[EMAIL PROTECTED]>
> | To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> | Sent: Tuesday, November 13, 2001 3:04 AM
> | Subject: Re: Tomcat: Distributed Session Management revisited
> |
> |
> | > On 13/11/2001 12:54 am, "Tom Drake" <[EMAIL PROTECTED]> wrote:
> | >
> | > > Mika:
> | > >
> | > > Thanks for the reply. Here's some more thoughts on this subject.
> | > >
> | > > The primary problem that I see with the collaborative method
> | > > (e.g. extending the multicast solution) is
> | > > that all sessions will have to be sent to all cluster nodes. The
> | > > number session updates that have to travel 'on the wire' is in
> | > > relation to the number of nodes in the cluster.
> | >
> | > Linear growth, that's the best we can aim for...
> | >
> | > > Further more, when a new tomcat is brought on-line, it must
> | > > somehow retrieve a copy of all active sessions from somewhere.
> | > > There is nothing in place for this currently. Using multicast
> | > > is problematic. If a multicast request is made then all other nodes
> | > > would respond with all sessions. So, some other approach would
> | > > need to be taken which would result in two protocols being used
> | > > to make this feature work. This seems too complicated.
> | >
> | > Not "that" complicated. Most of the work on elective processes has
been
> | done
> | > already in the scope of other projects, so, we would only need to
adapt
> it
> | > to our scope...
> |
> | I agree with Pier, in my view that's separating the "application layer"
> | (content) from the transportation control layer (where, how).
> |
>
> Point taken, however, I strongly believe in keeping things simple.
> I'd not want to introduce extra communication channels unless there
> there is a REALLY good reason to do so.
>
> | >
> | > > ---
> | > > Consider this scenario:
> | > >
> | > > A user establishes a session on node 1 (of a 10 node cluster),
> | > > Tomcat would create a new session and transmit it to the
> | > > multicast port, which would then transmit 10 copies of this
> | > > session (1 to each cluster node).
> | > > Now suppose that the next request from this user is sent to
> | > > node 2, which causes an 

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

Pier, Tom,

cool, the discussion is starting to become interesting. :-)

comments below:

- Original Message -
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 3:04 AM
Subject: Re: Tomcat: Distributed Session Management revisited


> On 13/11/2001 12:54 am, "Tom Drake" <[EMAIL PROTECTED]> wrote:
>
> > Mika:
> >
> > Thanks for the reply. Here's some more thoughts on this subject.
> >
> > The primary problem that I see with the collaborative method
> > (e.g. extending the multicast solution) is
> > that all sessions will have to be sent to all cluster nodes. The
> > number session updates that have to travel 'on the wire' is in
> > relation to the number of nodes in the cluster.
>
> Linear growth, that's the best we can aim for...
>
> > Further more, when a new tomcat is brought on-line, it must
> > somehow retrieve a copy of all active sessions from somewhere.
> > There is nothing in place for this currently. Using multicast
> > is problematic. If a multicast request is made then all other nodes
> > would respond with all sessions. So, some other approach would
> > need to be taken which would result in two protocols being used
> > to make this feature work. This seems too complicated.
>
> Not "that" complicated. Most of the work on elective processes has been
done
> already in the scope of other projects, so, we would only need to adapt it
> to our scope...

I agree with Pier, in my view that's separating the "application layer"
(content) from the transportation control layer (where, how).

>
> > ---
> > Consider this scenario:
> >
> > A user establishes a session on node 1 (of a 10 node cluster),
> > Tomcat would create a new session and transmit it to the
> > multicast port, which would then transmit 10 copies of this
> > session (1 to each cluster node).
> > Now suppose that the next request from this user is sent to
> > node 2, which causes an update to the session to occur. Again
> > 11 copies of the Session are transferred.
> > [...]
> > NOTE: remember this is UDP traffic. The more packets that
> > fly around, the greater the likely-hood of dropping packets.
> > Dropped packets in this case means that some tomcat
> > instances may have stale (or no) data for a given session.
>
> Indeed... Quite huge...

Yes, multicast udp should only be used to autoconfigure the cluster (who's
there, who's taking sessions etc.), which should also be configurable for
non-multicast-environments. In that case lists of adresses are used to
select who's the next to take over. In fact, if all node's are holding
information about the peers, we don't need to have long lists. An upcoming
node would need only one already configured node to ask the cluster's spread
via TCP. It's join could be communicated via daisy-chain. (one message per
member is linear).

>
> > --
> > With a centralized session manager the following traffic would
> > occur instead:
> >
> > node1 sends new session to server manager
> > node 2 requests the given (session id) session from the server manager
> > manager sends a copy of the session to node 2
> > node 2 updates the session and sends it back to the manager.
> > manager sends the 'invalidateSession(sessionId)' method in each of
nodes.
> >  (note: invalidateSession only contains the value of 'SessionId' + any
> > additional
> >   RMI overhead. This is far smaller than a complete Session object)
> >
> > The number of session copies sent as the result of an update is 2.
> > This number does not depend or vary based on the number of nodes.
> >
> > Now, let's add to the story. Let's say that Tomcat is smart enough to
cache
> > Session objects in it's memory space. Once Tomcat gets its hands on a
> > 'Session'
> > it keeps it until it becomes 'too old' or an
'invalidateSession(sessionId)'
> > message is
> > received from the remote Session Manager. This could cut down the the
number
> > of transfers of Session data from 2 to somewhere between 1 and 2.
>
> Yes, but in this case, we don't have redundancy of sessions... So, if the
> Tomcat which has the session dies, the whole session dies with him...
>
> > -
> > On Redundant Session Managers.
> >
> > There are a couple ways to achieve this. One way is to place two Session
> > Managers in the network. One of them is the 'active' one, the other one
could
> > simply register itself as a client of the 'active' server. As a client,
it can
> > obtain copies of all new and changed sessions from the active server. If
for
> > some reason the active server needs to be brought down, it will send a
message
> > to all of it's clients (including the 'dormant' session manager)
indicating
> > that it's shutting down. The clients could, on receipt of this message,
> > connect to the 'next' session server (in their pre-configured list of
> > servers). The clients co

Re: [JTC] latest mod_webapp stuff ?

[Mika Goeckel]

Hi Pier,

is the not working NumberGuess-Example (ClassCastException) with mod_webapp
also a recently fixed thing, or did I just screw the config?

Cheers, Mika
^X^C

- Original Message -
From: "Pier Fumagalli" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 1:17 AM
Subject: Re: [JTC] latest mod_webapp stuff ?


> On 12/11/2001 08:32 am, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > What about mod_webapp on JTC ?
> >
> > Could I get the latest stuff from CVS to let me build a
> > new mod_webapp RPM for Tomcat 4.0.1 ?
>
> Sure you can... The version in CVS should be fairly stable and with a
bunch
> of bugs fixed...
>
> One of these days there's also going to be a release (but first I still
have
> to find a proper job and buy a proper computer :) :) :)
>
> Pier
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

Hi,

I'm looking at the same area at the moment. and try to get my head around
it maybe we can help each other... further comments below.

- Original Message -
From: "Tom Drake" <[EMAIL PROTECTED]>
To: "Tomcat Dev List" <[EMAIL PROTECTED]>
Sent: Monday, November 12, 2001 11:19 PM
Subject: Fw: Tomcat: Distributed Session Management revisited


> Tomcat Developers:
>
> This is a forward of a message that I sent to Bip and Craig a few days
ago,
> regarding distributed session managment (aka Clustering). I haven't gotten
> any feedback just yet, so I thought I'd throw this out to the whole dev
> list.
>
> The current implementation is broken. The following message explains
> why and describes some possible solutions to this problem.
>
> This feature (e.g. distributed session management) is an absolute
> requirement
> for any deployment that needs to scale beyond a single Tomcat instance,
and
> does not want the overhead of depending on JDBC for storing sessions.
>
> I've also attached, at the bottom of this message, Two 'preliminary' RMI
> interfaces
> that describe (see scenario 1 below) how I think this session server and
> it's
> clients (e.g. tomcat instances) should converse.
>   SessionServer - to be implemented by the remote session manager/server
>   SessionClient - to be implemented by clients (e.g. Tomcat) of the remote
>   session manager/server.
>
> I'm interested in making a contribution in this area and am anxious to
> receive
> some feedback from the dev-list members on this subject.
>
> Regards,
>
> Tom Drake
> Email: [EMAIL PROTECTED]
>
>
> - Original Message -
> From: Tom Drake
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Sent: Saturday, November 10, 2001 10:48 PM
> Subject: Tomcat: Distributed Session Management revisited
>
>
> Bip:
>
> I've looked closely at the existing catalina distributed session
> management code, and determined that the following problems
> exist. Since, I'm new to the code, it's highly likely that I've missed
> something. Please correct any errors in my analysis, and provide
> any input / feedback. I'm interested in contributing to this and would
> greatly appreciate any input you can provide.
>
> Problems with current solution:
>
> - Session updates are not communicated to the other nodes in the cluster

No, session updates are frequently communicated to all other cluster members
through the DistributedManager.run() method [processPersistenceChecks();].
... a second look came up with that only idle sessions and overflow sessions
are replicated...

Anyway, that's a paradigm-thing... how accurate does a session need to be?
After every change or just every couple of seconds. Should be configurable.

<...>

I would vote for the cooperative approach, but I'd like to add some
thoughts:

Besides the primary session manager, there needs to be a backup session
manager that captures the changes of sessions as well and is the crown
prince of the primary session manager. This is to prevent sessions to be
replicated to all other cluster instances (memory overhead) but to stay on
the save side if the primary goes down (yep, both could crash, but what in
live is 100%?). In that case the crown prince would take over and another
cluster instance can take over the crown prince's role.

Which server the primary manager is, should be either configurable or
random. The cluster instances should be configurable. Multicast should only
be used if the cluster instances are not configured to find out what other
instances are there. The configuration should only specify the initial
state, further instances should be addable at any time without the need to
bring the cluster down.

Another thought is, do sessions need to be replicated in whole, or could
there be a way to replicate only the changes (network overhead). I know guys
that store loads of things in sessions. We had a case where a whole search
result (one complex object per row) was stored there, possibly up to a
couple of megs...

RMI would be my first approach as well, but I would try to keep the
communication details separated from the functional logic implementing the
cluster. This would enable us later on to choose other means like JavaSpaces
or JMS. RMI is the first choice if the cluster is near by, but what against
a cluster over a WAN if the requirements allow slow/deferred replication?
RMI could not do that job reliable.

Cheers, Mika
^X^C


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Problems getting Nightly Build nov-10-01 up

[Mika Goeckel]

billbarker01/11/11 19:31:01

  Modified:src/share/org/apache/tomcat/util/net
StreamHandlerFactory.java
  Log:
  Fix potential MT race condition problem.
  
  Shouldn't happen in normal usage, but why live dangerously?
  
  Revision  ChangesPath
  1.2   +2 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/net/StreamHandlerFactory.java
  
  Index: StreamHandlerFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/net/StreamHandlerFactory.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- StreamHandlerFactory.java 2001/11/10 04:56:16 1.1
  +++ StreamHandlerFactory.java 2001/11/12 03:31:01 1.2
  @@ -130,7 +130,7 @@
   private synchronized void loadProtocols() {
if(protocolString == System.getProperty(SYS_PROTOCOLS)) 
return;
  - protocolString = System.getProperty(SYS_PROTOCOLS);
  + String protocolS = System.getProperty(SYS_PROTOCOLS);
StringTokenizer tok = new StringTokenizer(protocolString,"|");
protocols.clear();
while(tok.hasMoreTokens()) {
  @@ -144,6 +144,7 @@
protocols.put(prot,protC);
}
}
  + protocolString = protocolS;
   }
   /** A connection-less URLStreamHandler to allow parsing-only URLs.
*/
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: