Re: serialization and newest tomcat
To make the long and short of it. Nothing in my application(s) should LIVE over
a restart.
So serialization does NOT make sense for me at all. Users timeout after
inactivity too which otherwise might be a good reason for using it (maybe it
would be fine there as the timeout is pretty long).
However I very much appreciate your explanation. I was employing ONE totally
static bean for constants, Utilities, (many could change during run time - e.g.
debugLevel) and general purpose methods that are useful to lots of beans (e.g
cleanNquote makes a string ready for SQL insertion). I HAD BEEN using another,
Application, to keep track of application dependent Vectors for quick look up.
Using your example, these two could be combined and I would NOT need to pass
around a handle to the bean called Application in my own version of UserInfo
(as an object without class for compilation purposes - I use javac not a tool
to build so cyclic compile problems must be handled carefully). I could just
use the one independent static bean - Utilities and simple Java imports - MUCH
easier.
On Thursday, January 16, 2014 5:45 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ray,
On 1/12/14, 8:45 AM, Ray Holme wrote:
[S]erialization causes some problems in apache-tomcat-7.0.35
I have several applications and run on fedora linux. I have used
many releases of fedora and tomcat.
My applications are characterized by a) all use a DB (firebird) b)
all use both jsp and java servlets c) all use transient java beans
for a round of interaction (user request - user response) d) all
have 1 or more session java beans for each user (login - logout) e)
all have 1 or more application beans (initialized at startup, can
refresh, passed around) f) all have an application specific jar and
share a common code jar
Long ago I added serialization to almost all of the java beans to
stop tomcat whining in the catalina.out file. This worked just fine
until the most recent tomcat release.
On my development machine, java changes build new jars and
apache/tomcat must be restarted to work right. Starting with the
new release, problems with connections happened.
After research, I discovered that the applications were going nuts
with connection requests and xinetd was shutting down the
connection factory service. It took a 30 minute wait (or reboot) to
fix this problem. My guess is that the application wide beans were
not only being made fresh as always happens (they use one
connection each to initialize), but that the serialized versions
were coming back up and trying to refresh causing lots of strange
connections to be created (if one is not passed, one is made and
there are many routines each needing a connection).
To solve this problem, I stopped serialization. This solved the
problem.
From the notes I got from others (thanks Mark and ...):
serialization can be stopped by putting this in many places - here
is one: appname/META-INF/context.xml
Manager pathname= /
Can I venture a guess as to one other important detail you have left
out? It sounds like some of the objects you are putting into the
user's session (HttpSession: the stuff getting serialized to disk
across web application reload or Tomcat stop/start) may have
references to those application-scoped objects. Here's an example of
what I mean:
public class GlobalBean
implements Serializable
{
}
public class UserBean
implements Serializable
{
private GlobalBean _global;
public UserBean(GlobalBean gb)
{
_global = gb;
}
}
... in your webapp's ServletContextListener:
init() {
...
ServletContext application = getServletContext();
application.setAttribute(globalBean new GlobalBean());
...
}
... in your servlet:
doGet() {
...
ServletContext application = getServletContext();
GlobalBean gb = (GlobalBean)application.getAttribute(globalBean);
HttpSession session = request.getSession();
session.setAttribute(userBean, new UserBean(gb));
...
}
If the above are all happening, then when you de-serialize the
UserBeans, they will de-serialize the GlobalBean instance along with
themselves. If your GlobalBean has to do a bunch of db access or
whatever to initialize itself, it will either have to do that on
deserialization to make itself sane, or it will be in a non-sane
state. In either case, you won't get the newly-created GlobalBean from
your ServletContextListener (or similar) and things may get ... weird.
If this is the case, and you don't really care about the user's
session info, then by all means: disable session serialization and be
done with it. If you need this to work -- or if you need your web
application's sessions to be distributable -- then you are necessarily
going to have to change something with your architecture in order to
get this kind of thing to work in a sane way. My recommendation would
be to pass a GlobalBean into any
Re: serialization and newest tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ray,
On 1/12/14, 8:45 AM, Ray Holme wrote:
[S]erialization causes some problems in apache-tomcat-7.0.35
I have several applications and run on fedora linux. I have used
many releases of fedora and tomcat.
My applications are characterized by a) all use a DB (firebird) b)
all use both jsp and java servlets c) all use transient java beans
for a round of interaction (user request - user response) d) all
have 1 or more session java beans for each user (login - logout) e)
all have 1 or more application beans (initialized at startup, can
refresh, passed around) f) all have an application specific jar and
share a common code jar
Long ago I added serialization to almost all of the java beans to
stop tomcat whining in the catalina.out file. This worked just fine
until the most recent tomcat release.
On my development machine, java changes build new jars and
apache/tomcat must be restarted to work right. Starting with the
new release, problems with connections happened.
After research, I discovered that the applications were going nuts
with connection requests and xinetd was shutting down the
connection factory service. It took a 30 minute wait (or reboot) to
fix this problem. My guess is that the application wide beans were
not only being made fresh as always happens (they use one
connection each to initialize), but that the serialized versions
were coming back up and trying to refresh causing lots of strange
connections to be created (if one is not passed, one is made and
there are many routines each needing a connection).
To solve this problem, I stopped serialization. This solved the
problem.
From the notes I got from others (thanks Mark and ...):
serialization can be stopped by putting this in many places - here
is one: appname/META-INF/context.xml
Manager pathname= /
Can I venture a guess as to one other important detail you have left
out? It sounds like some of the objects you are putting into the
user's session (HttpSession: the stuff getting serialized to disk
across web application reload or Tomcat stop/start) may have
references to those application-scoped objects. Here's an example of
what I mean:
public class GlobalBean
implements Serializable
{
}
public class UserBean
implements Serializable
{
private GlobalBean _global;
public UserBean(GlobalBean gb)
{
_global = gb;
}
}
... in your webapp's ServletContextListener:
init() {
...
ServletContext application = getServletContext();
application.setAttribute(globalBean new GlobalBean());
...
}
... in your servlet:
doGet() {
...
ServletContext application = getServletContext();
GlobalBean gb = (GlobalBean)application.getAttribute(globalBean);
HttpSession session = request.getSession();
session.setAttribute(userBean, new UserBean(gb));
...
}
If the above are all happening, then when you de-serialize the
UserBeans, they will de-serialize the GlobalBean instance along with
themselves. If your GlobalBean has to do a bunch of db access or
whatever to initialize itself, it will either have to do that on
deserialization to make itself sane, or it will be in a non-sane
state. In either case, you won't get the newly-created GlobalBean from
your ServletContextListener (or similar) and things may get ... weird.
If this is the case, and you don't really care about the user's
session info, then by all means: disable session serialization and be
done with it. If you need this to work -- or if you need your web
application's sessions to be distributable -- then you are necessarily
going to have to change something with your architecture in order to
get this kind of thing to work in a sane way. My recommendation would
be to pass a GlobalBean into any method on the UserBean that needs to
access it, rather than keeping a reference of any kind. It's kind of
like IOC except ... not really anything like that ;)
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJS2GDqAAoJEBzwKT+lPKRYOZcQAKEqbjKbJ3zYm8c6pShgltSj
IzJ0NwWEredE19MEB39p1JXRMP7AyfaPogyHLATQUyEcJWIP0MrWVDptRWXNlEYU
kbo3ybmJZGGn7MydLSzctzVZsLlgG58E+cta4WkShLtc72tTJq3Zv3T0XlH6RVaS
8LPuLluYwIGJ6OSPR4tH2/QDd26W6psIJdmqabh0Jbbw5rKaqr1l1+Ib2Yhj0XV1
W+LwAdZYc5RpHDvxKSsJd2lrql3yG2aRXAn2/BHxx0trO8ag25oBq9gfmezDOeyP
AwBWQI4ralPGr6cYDDKkgz5uILUsKWeoIneLXxeH9lN5qARm3le59waWPMnL/jjC
Md0BTIoLP8o1GAFboChDpVJWbLC029p4iLE7bzR1zzuz/g9dvsqcmKsT1mEEtdPi
usZ8sKg9X67KcYYfq2T0nKFtQTZF8YXUPjoUOPeC04p4VQsdi2saYLYJ7X2JPHDJ
A8odCpEm27u3aH7wUCb0EbQFqOce2KwCN3B9YPe0MBb709jBXmcb3Z00yQiZVecW
RaIC8/IU6seeOYG8PJTyLvNNLbcrRYU41mufmt+gx48EMZMPZe33yWa3mh4CBzaX
lTdscmOnRS4doOIjpA1n5wZgtUjcO91Q8rp23fov3WAE/FmC+OiQjBfUJ6UbcO21
1LsZanvSMh9ns8I8lgAU
=qSiT
-END PGP SIGNATURE-
-
To unsubscribe, e-mail:
Re: serialization and newest tomcat
On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote: I haven't been following this thread, but I wanted to clarify a couple comments here just to make sure someone reading this in the future doesn't get the wrong ideas. serialization causes some problems in apache-tomcat-7.0.35 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in production you might not want to do that. I guess it depends on your app and what's in the sessions though. From the notes I got from others (thanks Mark and ...): serialization can be stopped by putting this in many places The many places are context files. There are several locations where you can configure your application's context. - here is one: appname/META-INF/context.xml Manager pathname= / Again, just watch out as this will prohibit Tomcat from saving session data on restart. In other words, all session data is going to be lost on restart. Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: serialization and newest tomcat
OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as while tomcat is up - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I am talking about java beans that are part of the application and shared information available to all users. These MUST be initialized at startup (they are) and OLD serial copies are defunct (dangerous as they cause crazy connections to happen) when tomcat is restarted. S - here is the question: I would like to allow serialization, but tell Tomcat that certain beans should NOT be resurrected without me getting warnings in the log file when I don't mark them as serialisable. IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote: I haven't been following this thread, but I wanted to clarify a couple comments here just to make sure someone reading this in the future doesn't get the wrong ideas. serialization causes some problems in apache-tomcat-7.0.35 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in production you might not want to do that. I guess it depends on your app and what's in the sessions though. From the notes I got from others (thanks Mark and ...): serialization can be stopped by putting this in many places The many places are context files. There are several locations where you can configure your application's context. - here is one: appname/META-INF/context.xml Manager pathname= / Again, just watch out as this will prohibit Tomcat from saving session data on restart. In other words, all session data is going to be lost on restart. Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: serialization and newest tomcat
Oh, I missed one comment from Daniel before (embedded and I did not see on the first pass, sorry). No, you don't know the application so I would like to explain that some information kept in the shared application beans is very static, needs to be loaded from the DB and is used everywhere by every user. The number of hits to the DB would quadruple (at minimum) without these small tables being in memory. I waste maybe 5k of memory to reduce DB use in an active system and speed up user response time. This would be silly for a system that it NOT active. On Monday, January 13, 2014 8:38 AM, Ray Holme rayho...@yahoo.com wrote: OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as while tomcat is up - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I am talking about java beans that are part of the application and shared information available to all users. These MUST be initialized at startup (they are) and OLD serial copies are defunct (dangerous as they cause crazy connections to happen) when tomcat is restarted. S - here is the question: I would like to allow serialization, but tell Tomcat that certain beans should NOT be resurrected without me getting warnings in the log file when I don't mark them as serialisable. IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote: I haven't been following this thread, but I wanted to clarify a couple comments here just to make sure someone reading this in the future doesn't get the wrong ideas. serialization causes some problems in apache-tomcat-7.0.35 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in production you might not want to do that. I guess it depends on your app and what's in the sessions though. From the notes I got from others (thanks Mark and ...): serialization can be stopped by putting this in many places The many places are
Re: serialization and newest tomcat
On Jan 13, 2014, at 8:37 AM, Ray Holme rayho...@yahoo.com wrote: OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as while tomcat is up - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I'm referring to HttpSession. http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html Any thing you store on the session through the Servlet API will be persisted by Tomcat when it shuts down and restored when it restarts (unless you disable this behavior as you have). This allows you to restart Tomcat and not lose session data. If you want to see what your application is storing in the session, take a look at the Manager application. It allows you to browse through active sessions and view what has been stored there. I am talking about java beans that are part of the application and shared information available to all users. These MUST be initialized at startup (they are) and OLD serial copies are defunct (dangerous as they cause crazy connections to happen) when tomcat is restarted. Not following you here. Tomcat only serializes what you put into a session (javax.servlet.HttpSession). Anything else is up to your application. S - here is the question: I would like to allow serialization, Ok. Make sure any object you put into the session implements Serializable. but tell Tomcat that certain beans should NOT be resurrected Certainly one option is to not put them in the session, but you do have other options. See last comment. without me getting warnings in the log file when I don't mark them as serializable. They *must* be serializable. Otherwise you're going to get an exception. This is a requirement of Java serialization. IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. As I've mentioned, your beans must implement Serializable or they won't be able to be serialized and you'll see error. This is not an issue with Tomcat. It's a requirement of Java serialization. Tomcat uses Java serialization to persist your session data between restarts so it inherits this requirement. I would suggest that you look into how Java serializes your objects. If you don't like the default behavior, it provides you with the ability to control that process. One example, if you want to prohibit a field from being serialized you can mark it transient. Dan On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote: I haven't been following this thread, but I wanted to clarify a couple comments here just to make sure someone reading this in the future doesn't get the wrong ideas. serialization causes some problems in apache-tomcat-7.0.35 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they
Re: serialization and newest tomcat
IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. just don't add those beans to a session or if you do add them make sure that they are in containers and that those fields are transient then those fields (beans) are not serialized and they are null when they are deserialized (so you need to refill them if they are needed) -- Johan Compagner Servoy
Re: serialization and newest tomcat
I have (in the past) dealt with transient so OK, makes sense. Not familiar with putting in container to shield from Apache serialization. Will look for writeup. Thanks. On Monday, January 13, 2014 10:12 AM, Johan Compagner jcompag...@servoy.com wrote: IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. just don't add those beans to a session or if you do add them make sure that they are in containers and that those fields are transient then those fields (beans) are not serialized and they are null when they are deserialized (so you need to refill them if they are needed) -- Johan Compagner Servoy
Re: serialization and newest tomcat
On Jan 13, 2014, at 9:02 AM, Ray Holme rayho...@yahoo.com wrote: Oh, I missed one comment from Daniel before (embedded and I did not see on the first pass, sorry). No, you don't know the application so I would like to explain that some information kept in the shared application beans is very static, needs to be loaded from the DB and is used everywhere by every user. The number of hits to the DB would quadruple (at minimum) without these small tables being in memory. I waste maybe 5k of memory to reduce DB use in an active system and speed up user response time. This would be silly for a system that it NOT active. This is fine and seems to make good sense. You certainly don't want to overload your DB. How does this relate to the problem at hand though? You need to provide more concrete details. How are you loading this information? How are you storing this information in memory? What do you mean by shared application beans? How does this related to sessions and Tomcat serializing the data? Dan On Monday, January 13, 2014 8:38 AM, Ray Holme rayho...@yahoo.com wrote: OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as while tomcat is up - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I am talking about java beans that are part of the application and shared information available to all users. These MUST be initialized at startup (they are) and OLD serial copies are defunct (dangerous as they cause crazy connections to happen) when tomcat is restarted. S - here is the question: I would like to allow serialization, but tell Tomcat that certain beans should NOT be resurrected without me getting warnings in the log file when I don't mark them as serialisable. IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote: I haven't been following this thread, but I wanted to clarify a couple comments here just to make sure someone reading this in the future doesn't get the wrong ideas. serialization causes some problems in apache-tomcat-7.0.35 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects
Re: serialization and newest tomcat
Another option would be to read them from the db once, at system startup, and then keep them static from there. You're still hitting your db, but not on an ongoing basis. On 1/13/2014 9:02 AM, Ray Holme wrote: Oh, I missed one comment from Daniel before (embedded and I did not see on the first pass, sorry). No, you don't know the application so I would like to explain that some information kept in the shared application beans is very static, needs to be loaded from the DB and is used everywhere by every user. The number of hits to the DB would quadruple (at minimum) without these small tables being in memory. I waste maybe 5k of memory to reduce DB use in an active system and speed up user response time. This would be silly for a system that it NOT active. On Monday, January 13, 2014 8:38 AM, Ray Holme rayho...@yahoo.com wrote: OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as while tomcat is up - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I am talking about java beans that are part of the application and shared information available to all users. These MUST be initialized at startup (they are) and OLD serial copies are defunct (dangerous as they cause crazy connections to happen) when tomcat is restarted. S - here is the question: I would like to allow serialization, but tell Tomcat that certain beans should NOT be resurrected without me getting warnings in the log file when I don't mark them as serialisable. IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote: I haven't been following this thread, but I wanted to clarify a couple comments here just to make sure someone reading this in the future doesn't get the wrong ideas. serialization causes some problems in apache-tomcat-7.0.35 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). I'm not going to pretend to fully understand how your application works, but from what I took of this explanation it sounds like your application is stuffing a lot of unnecessary things into the session. Limiting that or taking a closer look at how those objects are being serialized is probably something you should consider. To solve this problem, I stopped serialization. This solved the problem. This certainly works, however it's worth nothing that you'll lose any session data when you restart Tomcat. For development that's fine, but in production you might not want to do that. I
Re: serialization and newest tomcat
Nice, I do that for many things, but not all of it. You are right, I probably could do that. Nice food for thought! :=] On Monday, January 13, 2014 11:31 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Jan 13, 2014, at 8:37 AM, Ray Holme rayho...@yahoo.com wrote: OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am defining session as login to logout of a USER as I mentioned before, perhaps you are defining this as while tomcat is up - I can see either def.). These type beans are all fine, but I would actually never want them serialized if Tomcat restarts as I would want the user to log back in for a lot of reasons (but no damage would be caused if they were serialized). I'm referring to HttpSession. http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html Any thing you store on the session through the Servlet API will be persisted by Tomcat when it shuts down and restored when it restarts (unless you disable this behavior as you have). This allows you to restart Tomcat and not lose session data. If you want to see what your application is storing in the session, take a look at the Manager application. It allows you to browse through active sessions and view what has been stored there. I am talking about java beans that are part of the application and shared information available to all users. These MUST be initialized at startup (they are) and OLD serial copies are defunct (dangerous as they cause crazy connections to happen) when tomcat is restarted. Not following you here. Tomcat only serializes what you put into a session (javax.servlet.HttpSession). Anything else is up to your application. S - here is the question: I would like to allow serialization, Ok. Make sure any object you put into the session implements Serializable. but tell Tomcat that certain beans should NOT be resurrected Certainly one option is to not put them in the session, but you do have other options. See last comment. without me getting warnings in the log file when I don't mark them as serializable. They *must* be serializable. Otherwise you're going to get an exception. This is a requirement of Java serialization. IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN? Right now, I have stopped warnings but caused other problems. As I've mentioned, your beans must implement Serializable or they won't be able to be serialized and you'll see error. This is not an issue with Tomcat. It's a requirement of Java serialization. Tomcat uses Java serialization to persist your session data between restarts so it inherits this requirement. I would suggest that you look into how Java serializes your objects. If you don't like the default behavior, it provides you with the ability to control that process. One example, if you want to prohibit a field from being serialized you can mark it transient. Dan On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com wrote: On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote: I haven't been following this thread, but I wanted to clarify a couple comments here just to make sure someone reading this in the future doesn't get the wrong ideas. serialization causes some problems in apache-tomcat-7.0.35 No. What causes problems is when application objects are placed in the session and they are not serializable. This happens because, by default, Tomcat will try to save your session data when it restarts. It does this by serializing the data to disk. Then when it restarts, it deserializes the data and restores the sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts The only other reason why your sessions would need to be serializable is if you're using clustering (i.e. you add the distributable tag to web.xml). I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was
serialization and newest tomcat
erialization causes some problems in apache-tomcat-7.0.35 I have several applications and run on fedora linux. I have used many releases of fedora and tomcat. My applications are characterized by a) all use a DB (firebird) b) all use both jsp and java servlets c) all use transient java beans for a round of interaction (user request - user response) d) all have 1 or more session java beans for each user (login - logout) e) all have 1 or more application beans (initialized at startup, can refresh, passed around) f) all have an application specific jar and share a common code jar Long ago I added serialization to almost all of the java beans to stop tomcat whining in the catalina.out file. This worked just fine until the most recent tomcat release. On my development machine, java changes build new jars and apache/tomcat must be restarted to work right. Starting with the new release, problems with connections happened. After research, I discovered that the applications were going nuts with connection requests and xinetd was shutting down the connection factory service. It took a 30 minute wait (or reboot) to fix this problem. My guess is that the application wide beans were not only being made fresh as always happens (they use one connection each to initialize), but that the serialized versions were coming back up and trying to refresh causing lots of strange connections to be created (if one is not passed, one is made and there are many routines each needing a connection). To solve this problem, I stopped serialization. This solved the problem. From the notes I got from others (thanks Mark and ...): serialization can be stopped by putting this in many places - here is one: appname/META-INF/context.xml Manager pathname= /
