Re: How to receive Session Manager from servlet?
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: 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
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]
Re: preferred method of handling empty form fields
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(); %
jsp:setProperty name=bean property=*/
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: load balancing - integration thoughts
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
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 Valve to AccessLogValve,RequestDumperValve,RemoteHostFilter 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 Logger and Realm 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
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: server.xml DTD/Schema
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 Connector. 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]
Re: Disable Refresh Function in IE
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: 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: [TC4] How to know when tomcat is properly shut down?
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: 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: Disable Refresh Function in IE
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: 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: 4.0.1 ClassLoader breaks singletons on webapp reload.
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: 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.
?? 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: Distributed Session Management
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: 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
- 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
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 could simply carry on with the new server. Indeed... If the active server simply goes off the air for some mysterious reason. The clients would get a
Re: Tomcat: Distributed Session Management revisited
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 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
Re: Tomcat: Distributed Session Management revisited
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
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
- 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat: Distributed Session Management revisited
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Problems getting Nightly Build nov-10-01 up
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 codeURLStreamHandler/code to allow parsing-only URLs.
*/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
