[cobalt-developers] XTR Kernel

["William L. Thomson Jr." <support@xxxxxxxxxxxxxxxxxxxx>]

Ok,
	So it's obvious now that the recent kernel update causes more problems
than it fixes. However Sun/Cobalt obviously is aware of some problem
with the old kernel, thus the attempt to fix it.

	I am not so concerned with the new problems, as I am hoping Sun/Cobalt
is working on a new release of the kernel update. I am however concerned
with the problem they are trying to address.

Our scenario
Raq XTR
1gb PIII
1gb ram
4x30gb hard drives

I run RAID 1 and 5 I think? Striping three, with one hot stand by
mirror?

The services currently in use.
WWW
SMTP/POP/IMAP
FTP
SSH

I also run
Tomcat 4.1.18 with JDK 1.4.1
MainStreet Credit Verification Engine

With that said this server has a decent load avg. Not so much proc usage
but heavy memory usage.

With my use of certain java apps with Tomcat like JGenerator, I do a
fair amount of server side caching.

Now I have had a problem for some time now with the server running out
of memory. Or more specifically java throwing out of memory exceptions
under Tomcat.

Now my order of blame so far has been

1.) Me/My code/logic/install
2.) Apps like JGenerator/JDBC drivers
3.) Tomcat
4.) OS/Kernel

Here is basically what happens. When I start Tomcat it slowly starts to
use more and more memory. To the point where usually every 3-5 days I
must restart Tomcat and Apache. Not a big deal, but a pain.

Now if I get the out of memory error, I restart Tomcat to free the
memory. Not all memory is freed. Some remains in cache, buffers, etc.
But it does not seem to release all of the memory. Nor will it ever.

Which basically causes me to every now and then, usually ever other
week, to have to fully restart and reboot the server. That is a huge
pain.

Now I have been through all code and etc so much that I am at the point
of blaming Tomcat. I have heard other complaints about Tomcat's memory
mis-management. Not sure if they are accurate though.

Either way I am trying to chase down the cause behind the server tying
up memory and not allow it to be freed?

Does this sound like the problem that Sun/Cobalt is trying to fix, thus
the kernel update?

Now on a side note, we as developers at times must assist Sun/Cobalt not
just bash them. We all make mistakes. I do not believe that Sun/Cobalt
intentionally put up a buggy kernel. Further more I do believe that the
kernel went through QA before it was released.

I am sure every developer out there would like a little more QA time
than is practical most times. Which was most likely the case there.

So as developers it's up to us to provide further QA type information
back to the OEM as to improve the product for us and others.

Now in this case I really appreciate those like Jan who installed the
update, had headaches and told us about them. However I as an outside
curious developer would like to know more details about the situation
than were provided. I am sure the Sun/Cobalt guys would like to know
even more.

(I am not complaining about you Jan, just making general
comments/statements)

So my point, in the future, as us developer complain about something,
let's all try to provide more details than are necessary. Not only to
inform our fellow developer, but to help out the guys making the
products.

I know we pay them for their products and services that should work
either way, but that does not mean we have no responsibility either.

Let's just try to do our part as well. Otherwise we should all just join
the users list and complain like a user.

-- 
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone  707.766.9509
Fax    707.766.8989
http://www.obsidian-studios.com