JMS-Connector question

[dialsc]

hello,

i our project we use several jms connectors connecting to an activeMq. reviewing our configuration files (we've got a lot ;) i figured out that the jms:activemq-connector generaly is always the same. given the following config example:

<jms:activemq-connector name="myMuleAppActiveMqConnector"
        clientId="myMuleAppActiveMqClient"
        brokerURL="tcp://localhost:4711" />

<jms:endpoint name="myMuleAppQueueEndpoint"
        connector-ref="myMuleAppActiveMqConnector"
        queue="myMuleAppQueuetopic />

do i see it right that we yould also define the activemq-connector once and reference it in all the jms:endpoint configurations we've got?

greez,

dialsc

[Andrew Perepelytsya]

One reason it may not work - you will run out of service threads if 1 connector is shared. The way you have it now - each connector corresponds to a single jms connection to the broker, and consumer/dispatcher count can be individually controlled per sub-system.

HTH,
Andrew

[dialsc]

hi,

thx a lot for your answer. i have to say that i do not understand the way it works in deepth so far. what i understood is that there is a thread being started for each jms-connector which handles all the muleEndpoints referencing it. so how could this run out of threads when there is only one?

the only thing i see is that one should take performance into consideration if only one jms-connector is being shared by all endpoints.

but in generell i'm interested in wheather i got it right or not. would sharing only one jms-connector work?

greez,

dialsc

Andrew Perepelytsya wrote:

One reason it may not work - you will run out of service threads if 1
connector is shared. The way you have it now - each connector corresponds to
a single jms connection to the broker, and consumer/dispatcher count can be
individually controlled per sub-system.

HTH,
Andrew

[Andrew Perepelytsya]

Jms connector is a bit special due to the nature of jms api. NumberOfConsumers attribute controls the listeners count for receiving messages. So if you have 10 endpoints receiving and only default 8 consumers, there simply isn't enough.

Unless there are some other restrictions, I don't see a reason why you should share a single connector, you would get a potentially better throughput and finer control over each group of endpoints. The other extreme is the resources availability, so you have to balance it and don't create thousands of unnecessary threads.

In general, specific values will depend on your system (defaults are good enough though).

HTH,
Andrew

On Nov 6, 2009 6:28 AM, "dialsc" <dirk.a.schaefer@...> wrote:


hi,

thx a lot for your answer. i have to say that i do not understand the way it
works in deepth so far. what i understood is that there is a thread being
started for each jms-connector which handles all the muleEndpoints
referencing it. so how could this run out of threads when there is only one?

the only thing i see is that one should take performance into consideration
if only one jms-connector is being shared by all endpoints.

but in generell i'm interested in wheather i got it right or not. would
sharing only one jms-connector work?

greez,

dialsc

Andrew Perepelytsya wrote: > > One reason it may not work - you will run out of service threads i...

--
View this message in context: http://old.nabble.com/JMS-Connector-question-tp26215741p26230315.html

Sent from the Mule - User mailing list archive at Nabble.com. ------------------------------------...

[Farrell, Kevin (ICTL_eCust_05)]

Sorry Andrew can you just elaborate on the point below because I don't fully get it.

 

If for example I have two queues and one connector that I've set numberOfConsumers to 1 does that mean one of the queues will never be polled? Or does it just mean the performance will be slower as it can only poll one queue at a time?

 

Regards,

Kevin.

 

-----Original Message-----
From: Andrew Perepelytsya [mailto:aperepel@...]
Sent: 06 November 2009 14:28
To: user@...
Subject: Re: [mule-user] JMS-Connector question

*************************************

This e-mail has been received by the Revenue Internet e-mail service. (IP)

*************************************

Jms connector is a bit special due to the nature of jms api. NumberOfConsumers attribute controls the listeners count for receiving messages. So if you have 10 endpoints receiving and only default 8 consumers, there simply isn't enough.

Unless there are some other restrictions, I don't see a reason why you should share a single connector, you would get a potentially better throughput and finer control over each group of endpoints. The other extreme is the resources availability, so you have to balance it and don't create thousands of unnecessary threads.

In general, specific values will depend on your system (defaults are good enough though).

HTH,
Andrew

On Nov 6, 2009 6:28 AM, "dialsc" <dirk.a.schaefer@...> wrote:


hi,

thx a lot for your answer. i have to say that i do not understand the way it
works in deepth so far. what i understood is that there is a thread being
started for each jms-connector which handles all the muleEndpoints
referencing it. so how could this run out of threads when there is only one?

the only thing i see is that one should take performance into consideration
if only one jms-connector is being shared by all endpoints.

but in generell i'm interested in wheather i got it right or not. would
sharing only one jms-connector work?

greez,

dialsc

Andrew Perepelytsya wrote: > > One reason it may not work - you will run out of service threads i...

--
View this message in context: http://old.nabble.com/JMS-Connector-question-tp26215741p26230315.html

Sent from the Mule - User mailing list archive at Nabble.com. ------------------------------------...

*********************************************************************

Please note that Revenue cannot guarantee that any personal
and sensitive data, sent in plain text via standard email,
is fully secure. Customers who choose to use this channel
are deemed to have accepted any risk involved. The alternative
communication methods offered by Revenue include standard post
and the option to register for our (encrypted) secure email service.
http://www.revenue.ie/en/practitioner/secure-email.html

*********************************************************************