Joseph B. Ottinger wrote:
> 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.
George, does the Sun MQ resource adapter close the objects during GC?
In any case, an application cannot depend on GC.
- Binod.
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>