Hi experts,
Mind if I join in to ask a for more detail on just how the connection
pooling works.
The environment I have is:-
Sun AS8.1 application server.
Generic RA 1.5
Sun Message Queue 3.6
The deployment in the app server has a connection pool containing a
minimum/maximum of 10 connections and the generic ra is configured to
lookup the administered objects in a directory server. (via ldap)
My web application will lookup the connection factory, open a connection
with the factory, open a session, lookup a queue, send a message then
close the producer, session and connection.
When I run the code I am aware that with one thread netstat reports 10
connections to the queues however they are all in the time_wait state.
I was expecting to see them in the established state. Does this mean
that when the pool is created it connects each factory to the queue
broker then drops the connection? From my testing it seems that I have
to call close() on the connection to return the object back to the pool,
ideally I would like this to not actually close the connection but leave
it connected ready for the next client to reuse the connection.
Any thoughts?
Many thanks
Donald
J. Seah wrote:
> Hi Binod,
>
> The connection pooling is fine, I was able to set it via that page. I
> was testing the JMS Pooled connections today and it was doing what it
> is supposed to do. It's just that the physical connections doesn't
> match up to physical connections.
>
> The tool i'm using is sys internals to view the physical connections
> which is essentially netstat I guess(?)
>
> I was reading through the genericra user guide again and saw that the
> Connection Exception Handlling is not yet tested successfully? Is this
> still the case? Have you got test cases that you would like me to test
> between SJSAS and MQSeries, I would be happy to offer my services if
> you require?
>
> anyway, thanks for your help
>
> Jonathon
>
>
>> From: Binod <Binod.Pg_at_Sun.COM>
>> Reply-To: users_at_genericjmsra.dev.java.net
>> To: users_at_genericjmsra.dev.java.net
>> Subject: Re: GenericRA and Connection Pooling
>> Date: Wed, 22 Mar 2006 21:11:36 +0530
>>
>> Hi Jonathan,
>>
>>> Hi,
>>>
>>> Got a question regarding Queue Connection Pooling.
>>>
>>> Here's the situation i've got a ejb which gets queue connections
>>> via the genericra. The ejb will send a message to a queue and
>>> receive a reply message via another queue so there should be at
>>> least 2 connections here right? What i've done is configured the
>>> maximum connection pool size to 4 on the Connector Connection Pool
>>> page via the asadmin web page. Why is that once I spawn 5 threads to
>>> send messages to my ejb, I have 9 physical tcp connections to my MQ
>>> Manager?
>>
>>
>> What is the steady-pool-size?
>>
>>>
>>>
>>> I've spawned 10, 15, 20 and 100 threads and it appears to have 9 tcp
>>> connections every time. Clearly it looks like the max pool size is 8
>>> (with an extra connection?? could you explain that bit as well?).
>>> Where do I correctly set the max pool size as I am at the point of
>>> tweaking the Generic RA so that it suits my organisation?
>>
>>
>> Under any condition, the max pool size will not exceed what is
>> configured in the connection
>> pool configuration. It could be that for 4 connections, MQ might be
>> using 2 connections each
>> to the database. Also, it is possible that there is one house keeping
>> connection created always
>> between MQ client and server.
>>
>> Have you tried increasing the max pool size to say 15 and checked the
>> number of tcp connections?
>>
>> Also, how are you checking the tcp connections? netstat?
>>
>> thanks,
>> - Binod.
>>
>>>
>>> I am using SJSAS8.1 on a WinXP machine running on JDK1.5
>>> MQSeries is running on a Solaris 8 server and is version 5.3
>>
>>
>> Thats fine :-)
>>
>> - Binod.
>>
>>>
>>> Thanks in advanced
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_genericjmsra.dev.java.net
>>> For additional commands, e-mail: users-help_at_genericjmsra.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_genericjmsra.dev.java.net
>> For additional commands, e-mail: users-help_at_genericjmsra.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_genericjmsra.dev.java.net
> For additional commands, e-mail: users-help_at_genericjmsra.dev.java.net
>