We've seen this, but with Interbase talking with some java servlets on
our tomcat server. I don't remember exactly how we fixed it, but I
think a code change to our application made the problem go away...
Sorry about the vague response, but it was years ago that we had this
problem. It was very frustrating because we could not kill the waiting
connections and it seemed to cause stability problems on the db servers
when they had so many of these sessions open at one time. From what we
could tell it was not a problem with the db server or the java server,
but with our code and how we were cleaning up the db connections in the
destroy method.

-steve

John B. Moore wrote:

> In a previous thread I discussed a problem I was having with Firebird
> on a specific machine.. I have now been tracking the behaviour of
> Firebird on the problem machine vs a machine that is working
> correctly. Both have the exact same OS & version, and Firebird &
> version. (CentOS 4.2 and latest Firebird SServer downloaded Sunday)
> and nearly identical hardware.
>
> On the Problem machine, when checking "netstat" and looking at the
> "gds_db" service connections I see mostly CLOSE_WAIT states.
>
>
> ========netstat===============
> tcp 21 0 mps-185.microps.com:gds_db mps-187.microps.com:34315
> CLOSE_WAIT
> ------------------------------
>
> Preliminary research on CLOSE_WAIT indicates this is "not a good
> thing" and indicates something is not responding or in someway
> finishing a connection or it is being dropped at one end and the other
> end does not know about it.. (My guess is that the db pooler is trying
> to use a connection that is in this state and failing)
>
> On the Machine that is working (and currently has all of the databases
> that were on the original problem machine), ALL connnections remain
> "ESTABLISHED" (observed over the last 24 hours) This would indicate
> to me that it is not the "outside" web application (Pooler) that is
> farkling the connections.
>
> In reading all of this, I need find out if there are any circumstances
> in which Firebird "might" contribute to a CLOSE_WAIT state. (Or might
> have any personal experience with a situation like this..) so if there
> is not, I can point my hardware vendor in the direction of a hardware
> problem (I'm trying to eliminate any software issues..)
>
> Thank you..
>
> John...
>
>
>
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>