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: Possible Apache Tomcat workshop after ApacheCon 2014
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 1/17/14, 2:32 AM, Mark Thomas wrote: Cross-posted to users and dev list. Please reply on the users list. All, There is the possibility of holding a Tomcat specific summit/workshop after ApacheCon 2014 [1] (i.e. Thursday 10th). If there is interest, I am happy to take the lead to organise this. My current thinking is for a workshop that is organised along the lines of a BarCamp [2] with a theme similar to that of the Tomcat users list so each session is a discussion about an issue one or more users is having. If space is available I'd like to follow this up on the Friday with a hackathon where the primary focus is fixing any bugs identified on Thursday and implementing any useful new features that were identified. Before I approach the conference organisers, I'd like to know if there is interest in this event and if folks are likely to attend. I'd expect the BarCamp/Hackathon to be free but I don't know for sure at this stage. Please reply to this thread if you would be interested in attending such an event. Also, if you have ideas on how to might be improved please reply with those too. I'm going to be at ApacheCon, and I'd be happy to participate in either or both events. As I don't have a great deal of problems with Tomcat itself, I'd probably be more on the helping or committing patches provided by attendees side of the fence. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS2zgZAAoJEBzwKT+lPKRYG1sP/3S94Wm0VjQitTqa6RXEy+VV k4c/WFi0nQJDiDm2wEwTQmT487S6o3eGubzGxnocziAcd/vHBKl4l5H9SfziNfL1 Y6KKcrlkv7UGUq4pXaeD9g+RV3Z/KyZYnYssY407es+sGBxsMfNaGFtJMnyoG6UR ILmzUcl3+8W24yLLh645F32KYBzX59mBW8ba+nJYKVjiUAX30EtgMKYoKf2Xk+G0 Cup+6dGPyFEcCkF7bjYbxH9B50nX9iMK3Rgq2w7e+1wl3DNP5n9dg/SZroPromCb Ihw5T/SI3kPiJoyEMgzHi7ydz/DVcAV3NJyJAUe/twickbApsStUh6z+J+CMc9yw itQn+JdLF3yQerId8TmRZCNVvnClSLn+e4CB/QvYvbsTiNlkc797ovj0pW7J/IcT WkY7UTdwyl8CUZMbUiOPJPVrc1svFjBUAAi7pSABpATvjgn3c2NrQLzCpTV4kUgl Vn7ON41zHZVewfLC23aEQQry/uq+Xbg7PX8EIeiYpXhDuVYCW/5rIl/sfBtlsOxu XSjK/VAwaU/zVnsMnb+tbMI0F5vSEuwVCrW+qU12zeZP+OCb5EiLDJHsPNseGllf 7QamI0HpYdN8TVyip0cG9E+BihQ9PrRWA9d3Qu6H8jumTSZ3TnISGUYhPAi6zpxT Iw8f1Ob6uWJEaO6eVo80 =6qF5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Oracle Application Server 10g R3 works fine with RK-1048 codepage but Tomcat 7.0.47 does not.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Тимур, On 1/17/14, 10:52 AM, Тимур Кулибаев wrote: Hello, Chris ! Thank you for your correspondence with me. I misleaded you a lot in the following part: +++For Tomcat 7: lang=ru-RU, content=Oracle UIX, +++charset=UTF-8 type=text/css Actually, charset=UTF-8 is applied only to link element: link rel=stylesheet charset=UTF-8 type=text/css Servlet source code does not define contentType. Oracle UIX- based servlet generates UIX-objects (*.uix) dynamically at user calls. UIX-objects are html-pages in fact and their header has no contentType element. It means that Tomcat must itself decide which code page is to be assigned to generated UIX-objects. It's the root of the trouble. I tried to use the following options to force Tomcat works in windows-1251: $ echo $JAVA_OPTS -XX:MaxPermSize=128M -Xms256m -Xmx1024m -Duser.language=ru -Duser.country=RU -Dfile.encoding=Cp1251 --also CP1251, windows-1251, Windows-1251 but no effect. Also, I added filter: filter filter-nameAddDefaultCharsetFilter/filter-name filter-classorg.apache.catalina.filters.AddDefaultCharsetFilter/filter-class init-param param-nameencoding/param-name param-valuesystem/param-value /init-param /filter filter-mapping filter-nameAddDefaultCharsetFilter/filter-name url-pattern*.uix/url-pattern /filter-mapping Did you try setting the encoding to UTF-8 instead of system? If you use system, do you get any encoding specifically set in your Content-Type headers? Can you dump the headers from a request and post both the complete request and complete response headers? Also mention which configuration you are using at the time. Developers who created UIX-servlet left our company. I'm not Java programmer. Is there any way to force Tomcat 7 implement dynamically generated UIX-objects by single-byte contentType ? Now actual contentType is Unicode. I think you're just going to want to use UTF-8 for the server-browser communication. Using the single-byte stuff with your database should be just fine, but don't subject anyone else to that stuff. The AddDefaultCharsetFilter *should* do the job, but you'll have to configure it correctly -- plus it's only a default. If some other code explicitly sets the content-type or character-encoding, then the Filter will do nothing. In your previous letter you put a number of questions, so to make my message as short as possible I answer to all your questions in attached file. Please see one also. This list strips attachments. It's no trouble to look through a long post. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS2zmBAAoJEBzwKT+lPKRYvDYQAILMhAF9hTPIPvJjFg3mne7w MryClW7fol7MrgRE6GWzf8vCLPSgqL16zXx9aVCdGcfqiYuOjAOMJZzElkUxj2HZ 9mhQJ60OgWk99JHHc9XT7HoFQa82F0ROpsvtKcQ5GEO7zeAU2ttvaHAQJ4QjWzZE IYgny7eVjjfGD5NTwXZkEzEFIeeLLlkgcN+VFacbRYDmfbLZGJSA9uCCaG6GPUKr f8KLHZKzcaTy28bINtGRyWIigzZBnMnd4LWEsjmgu39DksZAWz21TBtX0jJrawBV DVwohh9q3ayZatKV9TKR6WJ9Ee9JGM+LzzYFingnBj82Ca763HeanEJbYS1Q4Mv7 SebI0pnY0pKRqJFk9he8PMJZgOa5tvT1J6hR+OGKAQXNfiR7RUaMsmPtQdokN65U Q8C57AV77bVLCEYeU7ml5f7KMjkWedBCMigiL648L0RCNAiAaXpLNN0mRd9YLMUv mEhM5eV28pvLwnrLpmYQKo/JeOy8+7YxCoxYJulUmxINrE9K1DZ3VO3Sc15ALlAx TIfChU3/5LX5rXEL4QCvaVNl08lV3MhEe0gi6636cDgsLA3HHBNFeIWIgp0fiPbm vh7VY1OhOYwXizL4uxudhetaUIwhjmMGz+shRiq1VZeX7DooT6NzeRpWMDz+hVwa y5PzIQUJYvL7DlA6BHdm =xUvf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cannot connect from outside using Tomcat 7/APR/SSL on AWS Windows system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jeffrey, On 1/17/14, 5:06 PM, Jeffrey Janner wrote: [snip] I cannot connect from any system, anywhere, using the external IP address. I can stop the Tomcat7 and start the Tomcat6 and immediately connect from anywhere. [snip] Connector address=10.4.1.20 port=80 maxHttpHeaderSize=8192 [snip] Connector address=10.4.1.20 port=443 maxHttpHeaderSize=8192 Could it be as simple as having set the address attribute? I run in AWS and never bother setting the address attribute. I haven't had any problems with Tomcat 5.5.x - 8.0.x though I can't offhand remember if I've ever used APR with it (we don't typically use APR). What if you switch to BIO or NIO connectors? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS21yfAAoJEBzwKT+lPKRYyWoQAIOlRnH+MRPoHiy17HXvhij7 CJn36nvobv4KqJcVSjsEYCvnvnoyohEVZbSHpIt7oC0eOmprfGGqhzy3gPbZxTR8 1PNNw8Vkwe7dAP+MBZSNTRn9wxOjV/98oUNWXEo5ZRVosWgqAw5Bt6su41fyZUDL lzhU2Gf188gzxzygi3B0yrDnEvksKLGuEpNs3Y+579gFLHhfZh8uQ53AWyNhN9Pt +AMz4c8m7Wt6Nb9roDEJ8llge68kOBog/N2mfrgyUQSxpXOWrH4x0EwzK9zGxGUp GuB8u2X7PnAkrJ9hf07TgPd4rsOqfshNmIoMB8aGPPuaIvVdazSJLqSQfDmTloQl dvrLbRfd10aP3J45Xk3WEG4Uwt5iMssMg4wiSdD2mIeVXkDAYz/WtRjWrJISUtUe QKDPGWOOmgfx6Z1/73iyjoET4aabAby7eLvWDjFbs4Hq44YuPCoWvOHOZ18DI+5i 0kqvOaH99en7BJVWuUbCxq+oUA+pwzuQPtJ/nKaOh1ciVvv4HkFc8ulOQO6HM9TO Gtvh6h2WqNr8dFyd5BQ2NxoqZJ3O/gFsAhENaasLqtTigWsRZHIvfmibjrZEMUmC 5j6xkjGZjh7/nCoJdPvKXeaV/GDrirZ6xem7Ax1o5fso2PNyyJAuTjsVpXT04/b6 EWzc8CV4NSbc5E6LGlEn =Xffx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
