Joseph B. Ottinger wrote:
> Binod, the containers I used for JMS for 1.4 *did* have finalizers that
> closed the connections, so the resources weren't leaking.
Are you referring to other application servers/JMS implementations here?
AFAIK, the default JMS implementation which comes with GlassFish, Sun
Java System Message Queue, does not perform this clean-up during
finalization of their Connection/Session implementations. George
[copied] could clarify. I think this is a good request for enhancement,
if we don't do this today. George?
Until, then I am afraid, as Binod pointed out earlier, you might want to
close all JMS connections/sessions once they are done. Since the JMS,
Connector and JDBC implementations in GlassFish share the same
connection pool [1], you should be able to use the connection pool
statistics to size the pool for the application.
Thanks
--Siva.
[1]
https://glassfish.dev.java.net/javaee5/integration-tech/glassfish_connpooling.html
>
> On Wed, 3 May 2006, Binod wrote:
>
>>> *nod* Well, I appreciate everyone's willingness to look at my posts.
>>> I'm more than happy to admit I'm learning a heck of a lot of things
>>> at a single time.
>>>
>>> The worst part about all this is that with J2EE 1.4 and 1.3, I've had
>>> NONE of these problems. It's all my vast inexperience with Java EE
>>> and glassfish, specifically.
>>
>>
>>
>> It is simply because initial versions of J2EE 1.4 and 1.3.1 did not
>> have pooling for JMS.
>>
>> Didnt you have any issue in J2EE 1.4 FCS as well?
>>
>> - Binod.
>>
>>>
>>> On Tue, 2 May 2006, Binod wrote:
>>>
>>>> GlassFish reuse the same pool implementation for all resources. So,
>>>> yes, JMS will show symptoms similar to JDBC
>>>> w.r.t pooling.
>>>>
>>>> Glad that you crossed the issue :-)
>>>>
>>>> - Binod.
>>>>
>>>>> Okay, I figured out something of what had happened. It *was* a
>>>>> connection pool problem, and in retrospect, it makes perfect sense:
>>>>> boneheaded move on my part, partially exposed by someone who rather
>>>>> generously pointed out some information based on my review of
>>>>> Glassfish (which needs to be revised, since one of my complaints
>>>>> was based on my own error.)
>>>>>
>>>>> I made the mistake of thinking the connection pool was a JDBC
>>>>> connection pool. Bzzt. It was the CONNECTION FACTORY for JMS, being
>>>>> fired off by a filter which could generate a HUGE number of
>>>>> connections. That's definitely something in my code, both as
>>>>> something to be fixed in deployment *and* as something to change
>>>>> about how messages are fired off. (I need to check the filter to
>>>>> make sure it's not creating a connection per item, which would be
>>>>> an absurd concept, but hey... new codebase, entirely untuned.)
>>>>>
>>>>> Thank you for all who're paying attention. :)
>>>>>
>>>>> -----------------------------------------------------------------------
>>>>>
>>>>> Joseph B. Ottinger
>>>>> http://enigmastation.com
>>>>> Editor, http://www.TheServerSide.com
>>>>> joeo_at_enigmastation.com
>>>>>