camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-3193) After a longer connection loss to the jms server a jms endpoint does not work anymore even if the jms server comes back online
Date Mon, 04 Oct 2010 07:07:41 GMT

    [ https://issues.apache.org/activemq/browse/CAMEL-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62310#action_62310
] 

Claus Ibsen commented on CAMEL-3193:
------------------------------------

Yeah fixed queues on brokers which may not be able to automatic create the queues on demand
often causes admin overhead :)

I can see one issue if a patch will create a new temporary queue, if there was an exception
using the old one. 
In that cause I think you could lose messages which are in-flight (eg replies are expected
on the old temporary queue)

However it would fix the issue of new messages as they just use the newly created temporary
queue and it ought to just work.
But I bet this is better than _nothing_.

I will try to touch base with some AMQ committers and hear their point of view.

We are talking about Camel 2.5 on the dev forum. We are waiting for scalate 1.3 to be released.
But with good luck we may be able to start the release this week or start of next.

> After a longer connection loss to the jms server a jms endpoint does not work anymore
even if the jms server comes back online
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-3193
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-3193
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-jms
>    Affects Versions: 2.5.0
>            Reporter: Christian Schneider
>            Assignee: Christian Schneider
>             Fix For: 2.5.0
>
>         Attachments: ClientTest.java, patch.txt
>
>
> To recreate the problem you need a route with a jms inout endpoint that is configured
to use a temporary destination for replies. Till now I was only able to show the problem with
tibco ems.
> - Start broker
> - Start the jms consumer that replies to the request
> - Start the route 
> - Send a request/reoply exchange (should work)
> - Stop the broker
> - Wait long enough for the client to do a full reconnect (I used connectionFactory.setReconnAttemptCount(1)
on the client so I do not have to wait so long)
> - Start the broker -> The jms component will do a full new connect
> - Send a request/reoply exchange -> Now a InvalidDestination Exception happens
> The client route will not work anymore until a restart as it creates the temporary destination
only once and it is invalid now.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message