Re: slow shutdown with jsvc
Hi all again,
Now I had look at the source code of jsvc-unix.c.
It looks as jsvc always has to wait for the completion of the sleep(60)
call:
So I changed the code using usleep(20):
log_debug("Waiting for a signal to be delivered");
create_tmp_file(args);
#ifdef OSD_POSIX
log_debug("java_sleep");
java_sleep(60);
/* pause(); */
#else
log_debug("normal sleep");
/* old sleep(60); / * pause() not threadsafe */
usleep(20); /* 200ms */
log_debug("normal usleep done");
#endif
while (!stopping) {
#ifdef OSD_POSIX
java_sleep(60);
/* pause(); */
#else
/* old sleep(60); / * pause() not threadsafe */
usleep(20); /* 200ms */
#endif
}
remove_tmp_file(args);
log_debug("Shutdown or reload requested: exiting");
Now the shutdown is sufficient fast:
08/09/2007 10:33:54 14808 jsvc debug: normal usleep done
08/09/2007 10:34:15 14808 jsvc debug: Caught SIGTERM: Scheduling a
shutdown
08/09/2007 10:34:15 14808 jsvc debug: remove_tmp_file:
/tmp/14808.jsvc_up
08/09/2007 10:34:15 14808 jsvc debug: Shutdown or reload requested:
exiting
08/09/2007 10:34:17 14808 jsvc debug: Daemon stopped successfully
08/09/2007 10:34:17 14808 jsvc debug: Daemon destroyed successfully
08/09/2007 10:34:17 14808 jsvc debug: Calling System.exit(0)
08/09/2007 10:34:17 14807 jsvc debug: Service shut down
Is the old behaviour by design or did I made something wrong at building the
executable?
I used ./configure --with-java=pathtojava and make (I do not have
autoconf)
Are there better solutions?
Thanks Charly
SunOS server 5.8 Generic_108528-06 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
2007/9/8, charly <[EMAIL PROTECTED]>:
>
> Hi all,
>
> I am using jsvc on solaris to run tomcat on port 80 using a non root
> user. Startup and running seems to be ok.
> I use the jsvc -stop -pidfile to initiate a shutdown. this
> command waits until the shutdown is complete.
> But in my case it lasts very long until jsvc is actually doing the
> shutdown:
>
> Does anyone know what could be the problem ?
>
> I
Virtual hosts problem
Hi, I have just installed tomcat5.5 on my fedora 7 server, and I need to configure some virtual hosts for the first time. I have searched the internet for some conclusive guide, but none seem to work. this is what i have so far: www.micker.dk This works, except when i need to call classes from /WEB-INF/classes from a jsp not located in / I'm pretty sure the above is the wrong way of configuring a virtual host, but I can't get anything else to work. where have I screwed up? Thank you, Michael -- View this message in context: http://www.nabble.com/Virtual-hosts-problem-tf4405374.html#a12568129 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Virtual hosts problem
micker wrote: > I have searched the internet for some conclusive guide, but none seem to > work. You could always try the Tomcat documentation: http://tomcat.apache.org/tomcat-5.5-doc/virtual-hosting-howto.html > where have I screwed up? You set appBase == docBase I'll look into adding some more explict instructions to the HOW-TO. Using the above doc, the ROOT webapp should be deployed as a war at $CATALINA_HOME/webapps/stimpy/ROOT.war or as an exploded dir at $CATALINA_HOME/webapps/stimpy/ROOT Other webapps would be deployed as: $CATALINA_HOME/webapps/stimpy/foo.war $CATALINA_HOME/webapps/stimpy/bar.war etc Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Virtual hosts problem
> From: micker [mailto:[EMAIL PROTECTED] > Subject: Virtual hosts problem > > I have searched the internet for some conclusive guide, but > none seem to work. Why not read the actual Tomcat doc first? Besides the link Mark T provided, here's the general one for Tomcat-specific configuration: http://tomcat.apache.org/tomcat-5.5-doc/config/index.html If you do go searching the internet, make sure you only look at information for the 5.5 level. >unpackWARs="true" autoDeploy="true" > xmlValidation="false" xmlNamespaceAware="false"> Is this the only ? Is this the defaultHost for the ? If it's not the only one, make sure the appBase directory does not overlap with other 's appBase settings. If it is the only you'll have, you don't need to change what comes with Tomcat. >directory="logs" prefix="micker.dk\_log." suffix=".txt" > timestamp="true"/> elements are not supported in 5.5. > > elements should not be placed in server.xml; the preferred location is in the webapp's META-INF/context.xml file. Regardless, as Mark T pointed out, the docBase is invalid. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concurrency with HttpSession
I found this doc applicable "You can pass the HttpSession as parameter to an EJB method, only if all objects in session are serializable. This has to be consider as passed-by-value, that means that it's read-only in the EJB. If anything is altered from inside the EJB, it won't be reflected back to the HttpSession of the Servlet Container" More to the point of your test scenario: The pass-by-reference can be used between EJBs Remote Interfaces, as they are remote references. While it is possible to pass an HttpSession as a parameter to an EJB object, it is considered to be bad practice in terms of object-oriented design. This is because you are creating an unnecessary coupling between back-end objects (EJBs) and front-end objects (HttpSession). In any case could you post an the aforementioned where the session attributes are being modified so we can look at it.. Thanks/ M-- This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without making a copy. Thank you. - Original Message - From: "Bill Barker" <[EMAIL PROTECTED]> To: Sent: Friday, September 07, 2007 10:33 PM Subject: Re: Concurrency with HttpSession "lightbulb432" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I'm reading some book concurrency books that talk about potential thread safety issues with HttpSession. Specific cases follow: - When the web container passivates an HttpSession while a user's request modifies it Should be rare, but I don't see anything in the TC code to prevent it from happening on edge cases. If someone can construct an example, I'd be more than happy to look into it. - When the web container replicates an HttpSession while a user's request modifies it I believe that with pessimistic locking, this shouldn't happen. But I'm not an expert on the TC replication code :). - When multiple quick, successive requests from the same user access the same HttpSession Could somebody explain how Tomcat deals with the first two, and what steps web application developers need to take to avoid concurrency problems with all three cases above? Is it guaranteed that the passivated/replicated object is always a consistent view of the HttpSession? Thanks. -- View this message in context: http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Tomcat 5.5.25 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 5.5.25 stable. Apache Tomcat 5.5.25 incorporates numerous security updates and bug fixes. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-55.cgi Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.4/705 - Release Date: 2/27/2007 3:24 PM - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat 5.5.25 released
On 9/8/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: > > The Apache Tomcat team announces the immediate availability of Apache > Tomcat 5.5.25 stable. > > Apache Tomcat 5.5.25 incorporates numerous security updates and bug fixes. > Please refer to the change log for the list of changes: > http://tomcat.apache.org/tomcat-5.5-doc/changelog.html Thanks, but the above page does not contain the 5.5.25 release change yet:) Best - RuiXian Downloads: > http://tomcat.apache.org/download-55.cgi > > Thank you, > > -- The Apache Tomcat Team > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.446 / Virus Database: 268.18.4/705 - Release Date: > 2/27/2007 3:24 PM > > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [ANN] Apache Tomcat 5.5.25 released
Thanks, it's underway, syncing to mirrors as we speak Filip RuiXian BAO wrote: On 9/8/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote: The Apache Tomcat team announces the immediate availability of Apache Tomcat 5.5.25 stable. Apache Tomcat 5.5.25 incorporates numerous security updates and bug fixes. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html Thanks, but the above page does not contain the 5.5.25 release change yet:) Best - RuiXian Downloads: http://tomcat.apache.org/download-55.cgi Thank you, -- The Apache Tomcat Team - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.4/705 - Release Date: 2/27/2007 3:24 PM - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.9/994 - Release Date: 9/7/2007 4:40 PM - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to manage Apache error msgs when Tomcat is down?
Hi Eric, Eric B. wrote: Sorry - I guess I wasn't specific enough. The HTTP status code that I got from Apache was 200 hence the OK. I assumed that it was probably 200 since I was actually able to communicate with Apache itself, even though its request to tomcat was unavailable. Or unless I am missing something in my apache configuration to display the correct error page. If I check the headers sent using Fiddler, I get the following: HTTP/1.1 200 OK Date: Fri, 07 Sep 2007 18:04:51 GMT Server: Apache/2.0.52 (White Box) Content-Length: 501 Connection: close Content-Type: text/html; charset=iso-8859-1 However, it is definitely not "OK" b/c my tomcat server is down. Do I have something foobar'ed in my apache config? Or is it a problem in my mod_jk params? If it makes any difference, I am running mod_jk v1.2.10 w/ Apache 2.0.52. JK version 1.2.10 is very old. A lot of things changed until we now reached 1.2.25. Typically backend problems will be answered with a non 200 status code. Try a more recent version (like 1.2.25). Concerning error pages: In case Tomcat already sends an error status code, your webapps error page will be used. In case JK generates the error code itself, because it has trouble with the backend, the Apache httpd error page will be used. Thanks, Eric Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
the tomcat welcome file one struts action
Hello I am trying to make one web aplication using struts into one tomcat 5.0.XX In my web.xml file i writte whic is my welcome file, one struts action (Index.do) but the tomcat doesn't not show the action, shows me the all files from the index directory, listing my / directory. Can you help me for making the index file , welcome file, been one struts action (Index.do)? Thanks My web.xml file is this: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version="2.4" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> VeniveNicaragua javax.servlet.jsp.jstl.fmt.localizationContext /WEB-INF/classes/com/ApplicationResources Filtro Filtro com.gestor.Filtro Filtro / Filtro *.jsp Filtro /Index.do InitServlet com.gestor.servlets.InitServlet 1 action org.apache.struts.action.ActionServlet config /WEB-INF/struts-config.xml debug 3 detail 3 0 action *.do Index.do /WEB-INF/struts-bean.tld /WEB-INF/struts-bean.tld /WEB-INF/struts-html.tld /WEB-INF/struts-html.tld /WEB-INF/struts-logic.tld /WEB-INF/struts-logic.tld /WEB-INF/struts-nested.tld /WEB-INF/struts-nested.tld /WEB-INF/struts-tiles.tld /WEB-INF/struts-tiles.tld http://java.sun.com/jstl/fmt /WEB-INF/fmt.tld /WEB-INF/c-rt.tld /WEB-INF/c-rt.tld /WEB-INF/c.tld /WEB-INF/c.tld - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Connection pooling, is it the right way to do it?
Hi, i have done a server web application that runs on tomcat.
The server handle more clients and since i have to access to db, i tried to
implement the connection pooling.
Since i had some problems with tomcat (crashes after some days telling thatthe
connection pool was full, or something like it), i wish to be sure i'm doing
the right things to use the connection pool.
Anyway, after reinstall of tomcat, it seems to work a lot better than before,
but i still wish to know if the way i do it has sense.
The configuration of context.xml file is:
The setting in web.xml are:
...
DB Connection
jdbc/SomeAppDB
javax.sql.DataSource
Container
...
then i have a class with all methods that access to db, and it's like:
class Database {
private Connection getConnection() throws Exception {
// get context: provides the starting point for resolution of names
Context ctx = new InitialContext();
if (ctx == null) {
throw new Exception("No Context");
}
// retrieve datasource
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/SomeAppDB");
if (ds == null) {
throw new Exception("No Datasource");
}
// return db connection
return ds.getConnection();
}
public Object getSomething() {
Connection con = null;
Statement stmt = null;
ResultSet rst = null;
try {
// get connection
con = getConnection();
if (con == null) {
throw new Exception("No Connection");
}
stmt = con.createStatement();
// perform query
rst = stmt.executeQuery("SELECT something FROM some_table WHERE id =
'1'");
if (rst.next()) {
return rst.getString("something");
}
else {
throw new Exception("No results");
}
}
catch (Exception e1) {
return null;
}
// close resources
finally {
try {
rst.close();
rst = null;
}
catch (Exception e2) {
}
try {
stmt.close();
stmt = null;
}
catch (Exception e3) {
}
try {
con.close();
con = null;
}
catch (Exception e4) {
}
}
return null;
}
public Object getSomeOtherThing() {
Connection con = null;
Statement stmt = null;
ResultSet rst = null;
try {
// get connection
con = getConnection();
if (con == null) {
throw new Exception("No Connection");
}
...
}
...
>From all other classes of the application, i just use:
(new Database()).getSomething();
to call the method that access to db that i need.
Is it the correct way to use the connection pooling?
Database class should be done in a different way? For example, methods inside
it, should be static so i don't need to create each time a Database object just
to call one?
Any suggestion about it is very appreciated. Thanks
--
Leggi GRATIS le tue mail con il telefonino i-mode di Wind
http://i-mode.wind.it/
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: the tomcat welcome file one struts action
You may want to check on the Struts list. It could be a CASE SENSITIVITY issue. Does your app come up when you include Index.do in the URL? Miren Urkixo wrote: Hello I am trying to make one web aplication using struts into one tomcat 5.0.XX In my web.xml file i writte whic is my welcome file, one struts action (Index.do) but the tomcat doesn't not show the action, shows me the all files from the index directory, listing my / directory. Can you help me for making the index file , welcome file, been one struts action (Index.do)? Thanks My web.xml file is this: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; version="2.4" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> VeniveNicaragua javax.servlet.jsp.jstl.fmt.localizationContext /WEB-INF/classes/com/ApplicationResources Filtro Filtro com.gestor.Filtro Filtro / Filtro *.jsp Filtro /Index.do InitServlet com.gestor.servlets.InitServlet 1 action org.apache.struts.action.ActionServlet config /WEB-INF/struts-config.xml debug 3 detail 3 0 action *.do Index.do /WEB-INF/struts-bean.tld /WEB-INF/struts-bean.tld /WEB-INF/struts-html.tld /WEB-INF/struts-html.tld /WEB-INF/struts-logic.tld /WEB-INF/struts-logic.tld /WEB-INF/struts-nested.tld /WEB-INF/struts-nested.tld /WEB-INF/struts-tiles.tld /WEB-INF/struts-tiles.tld http://java.sun.com/jstl/fmt /WEB-INF/fmt.tld /WEB-INF/c-rt.tld /WEB-INF/c-rt.tld /WEB-INF/c.tld /WEB-INF/c.tld - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards Gabriel Wong Beyond Private JVM JAVA Hosting http://www.webappcabaret.com - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connection pooling, is it the right way to do it?
Hi.
1. Your docBase and path attributes are at best optional. As long as
your context.xml is delivered in your webapp's META-INF folder, it
should be used automagically.
2. I would trade the autoReconnect=true parameter to the database url
with a validationQuery attribute in the element. That
tells the db pool to do use the query to do a quick test of the
connection (and possibly recreate it) before you get it.
3. I see a lot of places where you catch and summarily eat the exception
with no logging or even passing it up to the method's caller. If you
don't pass it up and it's significant to the response, at least log it.
If you are throwing a new exception in response to an underlying
exception, pass the root cause along.
4. If the Database class is truly stateless (no class instance
variables) like what's listed, static methods are fine. However, I would
personally keep the DataSource object around after the first access in
some manner as a performance optimization for subsequent method calls.
Maybe something to the effect of:
db = new Database() ;
Object something = db.getSomething() ;
Object something2 = db.getSomeOtherThing() ;
In that case, store the DataSource object in the Database class and
don't make any methods static.
Otherwise it looks good. Have you tried the code?
--David
[EMAIL PROTECTED] wrote:
Hi, i have done a server web application that runs on tomcat.
The server handle more clients and since i have to access to db, i tried to
implement the connection pooling.
Since i had some problems with tomcat (crashes after some days telling thatthe
connection pool was full, or something like it), i wish to be sure i'm doing
the right things to use the connection pool.
Anyway, after reinstall of tomcat, it seems to work a lot better than before,
but i still wish to know if the way i do it has sense.
The configuration of context.xml file is:
The setting in web.xml are:
...
DB Connection
jdbc/SomeAppDB
javax.sql.DataSource
Container
...
then i have a class with all methods that access to db, and it's like:
class Database {
private Connection getConnection() throws Exception {
// get context: provides the starting point for resolution of names
Context ctx = new InitialContext();
if (ctx == null) {
throw new Exception("No Context");
}
// retrieve datasource
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/SomeAppDB");
if (ds == null) {
throw new Exception("No Datasource");
}
// return db connection
return ds.getConnection();
}
public Object getSomething() {
Connection con = null;
Statement stmt = null;
ResultSet rst = null;
try {
// get connection
con = getConnection();
if (con == null) {
throw new Exception("No Connection");
}
stmt = con.createStatement();
// perform query
rst = stmt.executeQuery("SELECT something FROM some_table WHERE id =
'1'");
if (rst.next()) {
return rst.getString("something");
}
else {
throw new Exception("No results");
}
}
catch (Exception e1) {
return null;
}
// close resources
finally {
try {
rst.close();
rst = null;
}
catch (Exception e2) {
}
try {
stmt.close();
stmt = null;
}
catch (Exception e3) {
}
try {
con.close();
con = null;
}
catch (Exception e4) {
}
}
return null;
}
public Object getSomeOtherThing() {
Connection con = null;
Statement stmt = null;
ResultSet rst = null;
try {
// get connection
con = getConnection();
if (con == null) {
throw new Exception("No Connection");
}
...
}
...
From all other classes of the application, i just use:
(new Database()).getSomething();
to call the method that access to db that i need.
Is it the correct way to use the connection pooling?
Database class should be done in a different way? For example, methods inside
it, should be static so i don't need to create each time a Database object just
to call one?
Any suggestion about it is very appreciated. Thanks
--
Leggi GRATIS le tue mail con il telefonino i-mode™ di Wind
http://i-mode.wind.it/
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Concurrency with HttpSession
I'm not talking about EJBs, but rather about any Tomcat-specific passivation that is done for HttpSessions that haven't been accessed in a while (just a memory use optimization). Regarding my question in general, I'm wondering (maybe this is more of a serialization question in general), if the container decides to serialize to disk a session with 10 attributes, and the following happens, wouldn't it result in an inconsistent serialized session? The container's thread finishes writing the first 5 attributes to disk, then a request's thread updates two session attributes (one from the first 5, one from the next 5), then the container writes the next 5 attributes to disk. You'd have an inconsistent serialized view, right? With only one of the two attribute updates reflected in the session. Sure, you'd assume that once a request accesses the session, the passivation would stop. Nonetheless, what thread-safety issues might arise with Tomcat in this case and others? I'm asking more for learning than any particular issue I'm having. mgainty wrote: > > I found this doc applicable > "You can pass the HttpSession as parameter to an EJB method, only if all > objects in session are serializable. > This has to be consider as passed-by-value, that means that it's read-only > in the EJB. > If anything is altered from inside the EJB, it won't be reflected back to > the HttpSession of the Servlet Container" > > More to the point of your test scenario: > The pass-by-reference can be used between EJBs Remote Interfaces, as they > are remote references. > While it is possible to pass an HttpSession as a parameter to an EJB > object, > it is considered to be bad practice in terms of object-oriented design. > This is because you are creating an unnecessary coupling between back-end > objects (EJBs) and front-end objects (HttpSession). > > In any case could you post an the aforementioned where the session > attributes are being modified so we can look at it.. > > Thanks/ > M-- > This email message and any files transmitted with it contain confidential > information intended only for the person(s) to whom this email message is > addressed. If you have received this email message in error, please > notify > the sender immediately by telephone or email and destroy the original > message without making a copy. Thank you. > > - Original Message - > From: "Bill Barker" <[EMAIL PROTECTED]> > To: > Sent: Friday, September 07, 2007 10:33 PM > Subject: Re: Concurrency with HttpSession > > >> >> "lightbulb432" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> >>> I'm reading some book concurrency books that talk about potential thread >>> safety issues with HttpSession. Specific cases follow: >>> >>> - When the web container passivates an HttpSession while a user's >>> request >>> modifies it >> >> Should be rare, but I don't see anything in the TC code to prevent it >> from >> happening on edge cases. If someone can construct an example, I'd be >> more >> than happy to look into it. >> >>> - When the web container replicates an HttpSession while a user's >>> request >>> modifies it >> >> I believe that with pessimistic locking, this shouldn't happen. But I'm >> not an expert on the TC replication code :). >> >> >>> - When multiple quick, successive requests from the same user access the >>> same HttpSession >>> >>> Could somebody explain how Tomcat deals with the first two, and what >>> steps >>> web application developers need to take to avoid concurrency problems >>> with >>> all three cases above? Is it guaranteed that the passivated/replicated >>> object is always a consistent view of the HttpSession? >>> >>> Thanks. >>> -- >>> View this message in context: >>> http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12561600 >>> Sent from the Tomcat - User mailing list archive at Nabble.com. >>> >>> >>> - >>> To start a new topic, e-mail: users@tomcat.apache.org >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> >> - >> To start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Concurrency-with-HttpSession-tf4403264.html#a12575563 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additiona
[OT] Correct action to take on log out
What are the things you do when a user logs out? Some options include invalidating the entire HttpSession, keeping the session alive but setting some attribute (e.g. "loggedIn") to false, or doing something else I haven't thought of. I was thinking that upon logout the simplest thing to do is invalidate the session, but there might be really valuable use cases that require a session to remain alive. For example, collecting data on and analyzing usage patterns for a given user while logged in and after logged out (for web applications that have plenty of functionality or content for users that are not logged in). What do your applications do on logout, and what have you seen other production applications do? What's the "best practice" in this regard? What are the tradeoffs I probably haven't thought of? Thanks. -- View this message in context: http://www.nabble.com/-OT--Correct-action-to-take-on-log-out-tf4407955.html#a12575609 Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SOLVED]: Problem with form based JSP authentication using Firefox with Tomcat
P, thanks very much for your help. The problem was fixed once I started linking explicitly to "/members/index.jsp" from index.htm, rather than just linking to "/members/" when my member file was straight html. > Date: Thu, 6 Sep 2007 15:12:28 +0100 > From: [EMAIL PROTECTED] > To: users@tomcat.apache.org > Subject: Re: Problem with form based JSP authentication using Firefox with > Tomcat > > Luke McMahon wrote: >> Thanks again P, > > Can you include the source of > > /index.html > > and > > /members/index.html (is it html or JSP?) > > > p > > >> Yeah I actually already had the meta tags at the top, and modified >> everything to match your example exactly. I also tried using separate login >> and error pages with no noticeable difference. >> Here are the http responses to the member page GET. I'm not well versed in >> this stuff, but it seems like the cache-control info is ok but it thinks the >> page has not been modified when the re-login fails: >> >> >> Success: >> - >> http://localhost:8080/members/ >> >> GET /members/ HTTP/1.1 >> Host: localhost:8080 >> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) >> Gecko/20070725 Firefox/2.0.0.6 >> Accept: >> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 >> Accept-Language: en-us,en;q=0.5 >> Accept-Encoding: gzip,deflate >> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >> Keep-Alive: 300 >> Connection: keep-alive >> Referer: http://localhost:8080/members/ >> Cookie: JSESSIONID=533286C2B979BBF186A7D69AAAE33746 >> Cache-Control: max-age=0 >> >> HTTP/1.x 200 OK >> Server: Apache-Coyote/1.1 >> Pragma: No-cache >> Cache-Control: no-cache >> Expires: Thu, 01 Jan 1970 10:00:00 EST >> Etag: W/"2807-1188956843361" >> Last-Modified: Wed, 05 Sep 2007 01:47:23 GMT >> Content-Type: text/html >> Content-Length: 2807 >> Date: Wed, 05 Sep 2007 02:03:55 GMT >> >> >> >> Failure: >> - >> http://localhost:8080/members/ >> >> GET /members/ HTTP/1.1 >> Host: localhost:8080 >> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.6) >> Gecko/20070725 Firefox/2.0.0.6 >> Accept: >> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 >> Accept-Language: en-us,en;q=0.5 >> Accept-Encoding: gzip,deflate >> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >> Keep-Alive: 300 >> Connection: keep-alive >> Referer: http://localhost:8080/members/ >> Cookie: JSESSIONID=FF03B0286AA97B1A603A05A1E402728D >> Cache-Control: max-age=0 >> >> HTTP/1.x 304 Not Modified >> Server: Apache-Coyote/1.1 >> Pragma: No-cache >> Cache-Control: no-cache >> Expires: Thu, 01 Jan 1970 10:00:00 EST >> Etag: W/"2807-1188956843361" >> Date: Wed, 05 Sep 2007 02:04:23 GMT >> >> >> >> >> >>> Date: Wed, 5 Sep 2007 09:46:53 +0100 >>> From: [EMAIL PROTECTED] >>> To: users@tomcat.apache.org >>> Subject: Re: Problem with form based JSP authentication using Firefox with >>> Tomcat >>> >>> Are you saying you tried what I suggested, or that you have already >>> tried it? It seems like the problem is a caching issue to me. >>> >>> What URL are you trying to access to trigger the login - you're not >>> accessing the login.jsp directly are you? (I have to ask...) >>> >>> >>> In the second instance the browser is setting JSESSIONID as a cookie, >>> instead of as a URL parameter, but that shouldn't make a difference. >>> The response.encodeURL method only encodes the URL with JSESSIONID if it >>> can't see the same value in a cookie in the request. >>> >>> The value of JSESSIONID *may* change with each new session, but it won't >>> be created until you hit a JSP. So the first time it's only created >>> when you hit login.jsp, where it's encoded in the URL because no >>> previous session id was found in the URL or cookie. >>> >>> The cookie still exists locally after you logout, until you close the >>> browser down, so it's not added to the URL the second time round, but as >>> the existing ID is an invalid session it triggers the authentication valve. >>> >>> >>> >>> You should compare the server response headers rather than the request >>> headers, to see if the server is correctly sending the Cache-Control info. >>> >>> >>> >>> p >>> >>> >>> >>> >>> >>> >>> >>> Luke McMahon wrote: Thanks p (hope this is formatted better!) I tried this without success. I've attached the livehttpheader output below. What seems to happen in Firefox is the first time I go to the login page, it passes the jsessionid to j_security_check. If I then invalidate the session, and go to log in again, it calls j_security_check without this identifier. This might be why I'm not getting redirected to the member page, but I'm not sure of that. Like I said, this works fine in IE, but firefox still seems to either be losing its bundle after the session is invalidated or incorrectly caching the login page
Re: Concurrency with HttpSession
You got my attention, so I was curious.
Looking at file:
java/org/apache/catalina/session/PersistentManagerBase.java
methods:
swapIn
swapOut
writeSession
findSession
(other related)
then the different stores load and save methods it
doesn't look good.
Basically, yes, you have an issue with Tomcat and
session passivation, unless I missed something else.
It does not have code for locking the session during
read and write.
What really needs to happen is a session needs to have
an instance variable which can be used for a
synchronization lock at the session level. In
ManagerBase.findSession, this lock would be used
before the session map is accessed. After the session
map is accessed it should then return null if the
session had been passivating before it was asked to be
found. It would then be loaded before it was ever
given back to be accessed. It would also be used in
PersistentManagerBase.swapOut like this:
protected void swapOut(Session session) throws
IOException {
if (store == null || !session.isValid()) {
return;
}
synchronized(session.locker){
//some check(s) needs to be added to see
//if the session was accessed before
//the call to initiate this process
//occurred
((StandardSession)session).passivate();
writeSession(session);
super.remove(session);
session.recycle();
}
}
This way a session can not be found before it is
completely written to disk/store. Some checks, as
mentioned in a comment in the code, need to be in
place to make sure the session was not accessed after
the method was called. It could be that the method is
called to begin right as the session has been accessed
and after the lock is released in findSession. So, you
would have a session and have some issues. Your user
would have a time when they thought they set something
or your code could think this then immediately the
changes are lost. Anyways, that is what looks to be
the issue.
The only way you could possibly *sort of* workaround
this issue would be to use a
HttpSessionActivationListener, but even then it would
be hard to code up a 100% reliable solution. You can
see how this would *sort of* be a way to work around
the issue by looking at the Tomcat class
StandardSession method passivate (in the same folder
as PersistentManagerBase.java), and see the events
will be thrown, but it would be pretty complicated and
ugly. This reminds me of the Session and Application
HashMap issue I mentioned before. It may not be the
case, but in that instance the developer thought
skipping the locks would speed up the server, but the
issue made it (Tomcat) less reliable and the speed
gain was by no means a match for the possible data
loss.
Do you want to file a bug or do you want me to? I'm
looking at the Tomcat 6.0.9 source code.
Wade
--- lightbulb432 <[EMAIL PROTECTED]> wrote:
>
> I'm not talking about EJBs, but rather about any
> Tomcat-specific passivation
> that is done for HttpSessions that haven't been
> accessed in a while (just a
> memory use optimization).
>
> Regarding my question in general, I'm wondering
> (maybe this is more of a
> serialization question in general), if the container
> decides to serialize to
> disk a session with 10 attributes, and the following
> happens, wouldn't it
> result in an inconsistent serialized session? The
> container's thread
> finishes writing the first 5 attributes to disk,
> then a request's thread
> updates two session attributes (one from the first
> 5, one from the next 5),
> then the container writes the next 5 attributes to
> disk.
>
> You'd have an inconsistent serialized view, right?
> With only one of the two
> attribute updates reflected in the session. Sure,
> you'd assume that once a
> request accesses the session, the passivation would
> stop. Nonetheless, what
> thread-safety issues might arise with Tomcat in this
> case and others?
>
> I'm asking more for learning than any particular
> issue I'm having.
>
>
>
> mgainty wrote:
> >
> > I found this doc applicable
> > "You can pass the HttpSession as parameter to an
> EJB method, only if all
> > objects in session are serializable.
> > This has to be consider as passed-by-value, that
> means that it's read-only
> > in the EJB.
> > If anything is altered from inside the EJB, it
> won't be reflected back to
> > the HttpSession of the Servlet Container"
> >
> > More to the point of your test scenario:
> > The pass-by-reference can be used between EJBs
> Remote Interfaces, as they
> > are remote references.
> > While it is possible to pass an HttpSession as a
> parameter to an EJB
> > object,
> > it is considered to be bad practice in terms of
> object-oriented design.
> > This is because you are creating an unnecessary
> coupling between back-end
> > objects (EJBs) and front-end objects
> (HttpSession).
> >
> > In any case could you post an the aforementioned
> where the session
> > attributes are being modified so we can
