Mark (et al):

At this point, I don't believe it is UTF-8 that is the problem.
I have done a lot of looking. Both of these applications were written
years ago and originally used my own home-brewed connection manager. It
was more forgiving and did not enforce timeouts. I think you hit the
nail on the head and I found that both of these applications do NOT use
my newer smarter FilterConnection java bean. I suspect connections are
not being properly released and possibly trying to live on with the
USER's connection instead of the roundtrip of a tomcat request.

We are researching this and will be making changes.

Thanks for your suggestion. It helped me look harder.

Ray

On Sun, 2014-04-06 at 13:25 +0200, Mark Rotteveel wrote:
>
> On 5-4-2014 19:55, Ray Holme wrote:
> > The following ridiculous changes to our DB Resource allow us to
> actually
> > do something for a short while - note that we used 10-20 time the
> times
> > we used normally
> >
> > ... validationInterval="300000"
> > timeBetweenEvictionRunsMillis="300000"
> > minEvictableIdleTimeMillis="600000"
> > removeAbandonedTimeout="600"
> >
> > I don't know if that helps define what is going on, but I guess
> > somewhere somehow we are timing out connections.
>
> removeAbandonedTimeout seems like the most obvious culprit. The
> connections if forcefully revoked after the specified timeout (in
> seconds): are there connections that are used for longer than 1
> minute
> (your previous config), or not closed after a request and reused at a
> later point?
>
> Although I am not sure how or why that would cause hangs without
> exceptions, etc.
>
> You can add logAbandoned="true" and logValidationErrors="true" to see
> if
> anything suspicious jumps out in the logs (see
> http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Common_Attributes
> (+ Enhanced attributes)).
>
> Mark
>
>
>