Re: serialization and newest tomcat

2014-01-18 Thread Ray Holme
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

2014-01-16 Thread Christopher Schultz
-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

2014-01-13 Thread Daniel Mikusa
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

2014-01-13 Thread Ray Holme
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

2014-01-13 Thread Ray Holme
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

2014-01-13 Thread Daniel Mikusa
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

2014-01-13 Thread Johan Compagner


 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

2014-01-13 Thread Ray Holme
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

2014-01-13 Thread Daniel Mikusa
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

2014-01-13 Thread David kerber
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

2014-01-13 Thread Ray Holme
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