Howdy,
You're putting too many things in one message. ;)

>Oracle Connection Pool
>We have observed that the number of connections during site outages are
>going beyond 1000 connections. These 1000 connections are jointly held
>by 12 tomcats with each tomcat having a separate pool. The min amd max
>connections are set to 30 and 100 respectively. The connections are not

So with your configuration, you'd always have between 30*12 = 360 and
100*12 = 1200 open database connections.  Is this really what you want?
If your DB can't handle 1000 connections, much less 1200, configure your
pools so that they don't reach this max.

>dumps of the respective tomcats JVM, it was observed that there were a
>lot of thread waiting on monitor. This we suspect is nothing but a lock
>all these threads are trying to acquire for closing the logical
>connection and have the threaddumps pointing to this too (not sure!!!).

Not sure is right.  Threads could be waiting on a lot of things, and
it's not always bad to wait (e.g. idle HTTP processor threads).  Which
threads were waiting and was it for a common monitor address?

>Since they are all stuck and in the wait state for longer period, it
>seems there might be some issue with the oracle connection pool. There
>is one oracle connection cleanup thread that runs too and seems that
>this is getting killed.  Moreover we have recently upgraded from

What is killing the oracle reaper?

>jdk1.3.1 to jdk1.4.2 and wondering if the jdbc drivers are compatible
>with the new JVM. The version we are using of oracle is 8.1.7.3 and
>classes12.zip. I don't know whether this would be right mailing list
but
>wanted to know if there are any known bugs for classes12.zip and if the

What is the date of the drivers in classes12.zip?  And you've renamed it
classes12.jar, right?  There are better drivers that come with Oracle 9i
(v9.2.0.1), the file is called ojdbc14.jar, and it's
backwards-compatible for Oracle 8i.  You should try these.

>Memory leaks in the application are continuosly causing high memory
>usage of the production servers. One observation which was observed on

Then fix the memory leaks.

>during the week was that amount of memory was reducing in a day to day
>scenario. This was observed from the 'TOP' display. Moreover, looking
at
>the GC logs of tomcats it was found that memory was on the rise on the

The JVM will use as much memory as you let it.  Monotonic increase is to
be expected when you look at it via the top command.  What you're more
interested in is the %free of the heap.  See how well your apps run if
you reduce max memory from 1GB to say 256MB.

>occasion where the total memory of the machine was 4GB. I am attaching
a
>file that can help give you some thing to comment on - GC Logs.

Attachments didn't come through, and a GC log wouldn't be very
meaningful to us anyways.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to