On Fri, Oct 30, 2009 at 11:33 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
>
> Heh. Obviously, someone hasn't worked in the real world. Did he realize
> that writing to the contract in this case could potentially bring-down
> the database server?
>
>
Eh, I just let it go. I'm beyond the fact that I know the code I wrote and
inherited is wacked. It's not worth starting an internet flame war,
especially over a programming topic on the sun board. I respect the other
people on there too much to make the guy look like an..... well we all get
the point.
> > Thank goodness I archive the tomcat udev / user listing in my Gmail.
>
> You can always search the archives on markmail, too. There's no need to
> keep your own archive.
>
I don't "actively" archive them, I have them auto sorted and split into
categories. I have 7GB+ of storage, so all of my Tomcat / PHP / C++ / etc
mails are all sent to different folders and marked accordingly. I knew
about markmail,
>
> > The main problem I was having was similar to what he was. I was able to
> > solve my problem by the following:
> >
> > maxActive="-1" maxIdle="5" maxWait="15"
> > removeAbandoned="true" removeAbandonedTimeout="15"
> > testWhileIdle="false" timeBetweenEvictionRunsMillis="900"/>
>
> 900ms is a /very/ short time for an eviction run. Given that you have a
> 15-second timeout, I would probably make your eviction runs somewhere in
> that range rather than in the sub-second range. Do you really want your
> DataSource waking up every second to check all the connections?
>
OOPS, good catch, should have been 54000ms (15 sec) I forgot to x by another
60 in there.
>
> > I changed up 4 parameters in the context.xml file. maxWait,
> > removeAbandonedTimeout, testWhileIdle, and timeBetweenEvictionRunsMIllis.
> > The problem was despite me closing the rs's in the program, MySQL &
> Tomcat
> > was still seeing the connections as active and would keep them open.
>
> Well, you have to close all your resources, not just ResultSets. Closing
> a ResultSet does not close the connection (nor does it return it to the
> pool, which may have been your whole problem).
>
> > I started by trying to tweak the wait timeout settings in the my.ini
> file,
> > but that really caused some jams especially if the connections would
> > timeout, then for some reason go to become active again, Tomcat would
> throw
> > me an error, so changing the settings on MySQL was not the answer.
>
> You really ought to use validationQuery="/* ping */ SELECT 1" as well.
> Any connection that has been closed while sitting in the pool will be
> re-checked before it's given-out to the caller. That means that you
> shouldn't get connection exceptions being thrown when this kind of thing
> happens.
>
I need to look into this to see how I need to implement it. (there is a
nice example down lower in this "thread")
>
> > The
> > problem was with how Tomcat was handling the time frame for recycling
> > connections. I cut the time that tomcat held on to the closed
> connections
> > and the problem remarkably went away. I could also monitor this from the
> > MySQL Administrator panel in real time when I ran heavy load queries to
> the
> > DB. Now every 15 seconds after a close, the connection is returned to
> the
> > pool. That seems to be about perfect, just long enough to run gc() and
> > continue on.
>
> Heh. I highly recommend reviewing you code: abandoned expirations and
> evictions can get you by in a pinch, but it's no way to live long-term.
> Fix your resource leaks and your server(s) will thank you by increasing
> their throughput.
>
Oh this code BLEEDS resources. The only semi annoyance is that the methods
that get RS's are usually returned like:
return
ConnectionPool.getConnection().createStatement().executeQuery(sqlCode);
This is not bad, but there is NO PLACE in the code that actively closes all
of the resources. Sometimes the code is LUCKY to have a call that is to
rs.close(); but I am more than positive that there is no statement /
connection closing going on. The hardest part is that everything is mixed
into the presentation layer. I'll fix the DAO first, then move to more
back-end fixing. Thanks for the 411 about the StatementFinalize and the
Millis timeout. The millis has been changed to 54000 (15 seconds), and I'll
look up more info about the StatementFinalize and the validationQuery.
This biggest problem I'm having is that I'm the only coder in a .NET shop
(they all run IIS and code in .NET only) and no one has experience with TC
except me. Honestly if it wasn't for this list and the sun forums, I'd be
sunk on most things Tomcat / java wise. This list with the members have
been an invaluable asset to my learning Tomcat.
>
> Good luck,
> - -chris
>
Thanks, Josh
