Yes, me again. I added code to explicitly free JMS connections I use to
*send* messages (I have a utility class to manage all the JMS plumbing for
me). Calling close on the Producer, Session, and Connection brings the
NumConnUsed for the JMS connection factory down to 0 (with a high water
mark of 1, which is entirely what I rather expected).
Therefore, the question now becomes one of: Is this correct? I'd think
that as the GC collected the Session, producer, and connection, that
they'd be closed along the way, but it doesn't look like that's happening.
On Tue, 2 May 2006, Joseph B. Ottinger wrote:
> Sorry to reply to my own message, but I've set up monitors on the connection
> factory, and the NumConnUsed always goes up - which seems a little
> suspicious. The JDBC connection pool shows 0 connections used while the
> system's inactive (i.e., quiescent, no data moving through the system) which
> is what I'd expect.
>
> So unless I'm supposed to do something to explicitly free those connections -
> a possibility, although an oddity - I'm wondering if we DO have a leak here.
>
> On Tue, 2 May 2006, Joseph B. Ottinger wrote:
>
>> Yes, I'm back. I'm still suffering from my connection leak with JMS, and
>> I'm not sure where or why; everywhere a session was used, the session goes
>> out of scope (although the ConnectionFactory doesn't, as it's injected via
>> @Resource). I've explicitly added close()s for the producer, session,
>> connection, but I have little confidence that this will actually fix
>> things.
>>
>> I'm of the (admittedly shaky) opinion that I'm not purposefully holding on
>> to resources. (Again, I'm not allocating them; they're injected.) It's
>> possible that I'm participating in transactions that last a while (message
>> -> MDB which uses a DAO and potentially sends another message or set of
>> them...) and things are getting hung up there, but the data IS getting
>> committed.
>>
>> So... what's the best way for me to find out where a connection is being
>> allocated and deallocated? I don't have a problem wading through a lot of
>> logs, if I'm confident that the data can be there.
>>
>> -----------------------------------------------------------------------
>> Joseph B. Ottinger http://enigmastation.com
>> Editor, http://www.TheServerSide.com joeo@enigmastation.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
> -----------------------------------------------------------------------
> Joseph B. Ottinger http://enigmastation.com
> Editor, http://www.TheServerSide.com joeo@enigmastation.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
-----------------------------------------------------------------------
Joseph B. Ottinger
http://enigmastation.com
Editor,
http://www.TheServerSide.com joeo@enigmastation.com