[mule-jira] Created: (MULE-4600) JMS-Connector doesn't reconnet to queue

JMS-Connector doesn't reconnet to queue
---------------------------------------

                 Key: MULE-4600
                 URL: http://www.mulesource.org/jira/browse/MULE-4600
             Project: Mule
          Issue Type: Bug
          Components: Transport: JMS
    Affects Versions: 2.2.1
         Environment: ActiveMq, Java 1.6
            Reporter: Dirk Alexander Schaefer


hello,

i'm very unhappy with the way the jms-connector and the retryPolicy concept are playing together in the case of an unavailable queue. i'm not quite sure if filling out a bug report is correct or if it better should be an enhancement request but at the end of the day i tend to see it as a bug. i also started a thread in the nabble-form about it, to be found here: http://old.nabble.com/JMS%3A-Howto-reconnect-on-connection-lost-to26206517.html

here are my thinkings:

i've been playing around with retryPolicies in order to get reconnected to the jms once the queue has crashed and restarted. up to now i was able to write a custom etryPolicy which does the job but i'm very unhappy with this sollution. two things about it.

1. if the queue turns off, mule doesn't reconnect to it at all until i start using a retryPolicy.
2. if the connection to the queue has been lost, messages from the queue to the mule instance can and will never be received by mule once the queue is up again.

in generell i've got the following possibilities with retryPolicies:

1. use one that tries to deliver a message for a configured amount of times.
2. use one that tries to deliver a message endless.

both of them do block any request (thread) until the queue gets available. but i do not want to have all request blocked until then. i need to have an exception thrown in such cases. if each request is being blocked, how log will it take until mule runs out of threads? furthermore i cannot accept to have clients waiting for responses until any timeout occurs for nothing. i want them to receive an exception. i'm trying to integrate mule in an environment with heavy load and very high demands for reliability and performance. i cannot not go any further with such a behaviour or i do not see the way, at least.

for sure there is the possibility to use asynchronous retryPolicies but they bring another problem into the game. first of all its only available in the enterprise edition which is - as you certainly know - incredible expensive. second and, here comes the real problem, for each request a new retryPolicy "worker" (thread) is being started. once the queue is available, the first one "wins" and the connector gets reconnected. but all the other retryPolicyWorks are still there and still try to do their job. but once the connection has been reestablished, there will always be an exception thrown that there is already a client using cientId XY connected to the queue and therefore all these retryPolicyWorkers keep working for ever as they keep receiving exceptions (JMSException).

what i need, and i'm absolutly sure lot of other people too, is a simple behaviour of the jmsConnector. throw an exception when the queue is not available and try to reconnect to it until its up again. this is such a simple and expected behaviour i cannot believe that it is not implemented this way. in my opinion how mule handles this is conceptually wrong. actually mule's retryPolicy concept for sure is a good thing if you whant exactly such things but blocking requests and|or starting multiple threads where only the first one gets "stopped" after a reconnect is just wrong.

from my point of view we need to get the possibility to get it working the way i described it above where the connector it self trys to reconnect to the queue without the need of retryPolicies. of course it could be integrated into mule thus this behaviour would be configurable but being able to tell mule - the jmsConnector - to work this way is something we realy need.

greez,

dirk

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.mulesource.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

     [ http://www.mulesource.org/jira/browse/MULE-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Perepelytsya closed MULE-4600.
-------------------------------------

    Resolution: Won't Fix or Usage Issue

Can't act on such report, continue discussion on the list.

> JMS-Connector doesn't reconnet to queue
> ---------------------------------------
>
>                 Key: MULE-4600
>                 URL: http://www.mulesource.org/jira/browse/MULE-4600
>             Project: Mule
>          Issue Type: Bug
>          Components: Transport: JMS
>    Affects Versions: 2.2.1
>         Environment: ActiveMq, Java 1.6
>            Reporter: Dirk Alexander Schaefer
>            Assignee: Andrew Perepelytsya
>
> hello,
> i'm very unhappy with the way the jms-connector and the retryPolicy concept are playing together in the case of an unavailable queue. i'm not quite sure if filling out a bug report is correct or if it better should be an enhancement request but at the end of the day i tend to see it as a bug. i also started a thread in the nabble-form about it, to be found here: http://old.nabble.com/JMS%3A-Howto-reconnect-on-connection-lost-to26206517.html
> here are my thinkings:
> i've been playing around with retryPolicies in order to get reconnected to the jms once the queue has crashed and restarted. up to now i was able to write a custom etryPolicy which does the job but i'm very unhappy with this sollution. two things about it.
> 1. if the queue turns off, mule doesn't reconnect to it at all until i start using a retryPolicy.
> 2. if the connection to the queue has been lost, messages from the queue to the mule instance can and will never be received by mule once the queue is up again.
> in generell i've got the following possibilities with retryPolicies:
> 1. use one that tries to deliver a message for a configured amount of times.
> 2. use one that tries to deliver a message endless.
> both of them do block any request (thread) until the queue gets available. but i do not want to have all request blocked until then. i need to have an exception thrown in such cases. if each request is being blocked, how log will it take until mule runs out of threads? furthermore i cannot accept to have clients waiting for responses until any timeout occurs for nothing. i want them to receive an exception. i'm trying to integrate mule in an environment with heavy load and very high demands for reliability and performance. i cannot not go any further with such a behaviour or i do not see the way, at least.
> for sure there is the possibility to use asynchronous retryPolicies but they bring another problem into the game. first of all its only available in the enterprise edition which is - as you certainly know - incredible expensive. second and, here comes the real problem, for each request a new retryPolicy "worker" (thread) is being started. once the queue is available, the first one "wins" and the connector gets reconnected. but all the other retryPolicyWorks are still there and still try to do their job. but once the connection has been reestablished, there will always be an exception thrown that there is already a client using cientId XY connected to the queue and therefore all these retryPolicyWorkers keep working for ever as they keep receiving exceptions (JMSException).
> what i need, and i'm absolutly sure lot of other people too, is a simple behaviour of the jmsConnector. throw an exception when the queue is not available and try to reconnect to it until its up again. this is such a simple and expected behaviour i cannot believe that it is not implemented this way. in my opinion how mule handles this is conceptually wrong. actually mule's retryPolicy concept for sure is a good thing if you whant exactly such things but blocking requests and|or starting multiple threads where only the first one gets "stopped" after a reconnect is just wrong.
> from my point of view we need to get the possibility to get it working the way i described it above where the connector it self trys to reconnect to the queue without the need of retryPolicies. of course it could be integrated into mule thus this behaviour would be configurable but being able to tell mule - the jmsConnector - to work this way is something we realy need.
> greez,
> dirk

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.mulesource.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email