FAQ
Hello

I am using Camel 2.4.0 with Spring DSL and ActiveMQ 5.4.2. I have a route
that takes a message off a queue, grabs the correlation ID in order to
create a file name, and then FTPs the message. I expected that any exception
during this process would "roll back" so that the message would not be
pulled off the queue. FTP was unavailable due to some firewall changes, so
my messages got pulled off the queue but never FTPd.

I understand that if I use Camel 2.5 I can use
throwExceptionOnConnectionFailed. My questions are:
1. Will that prevent the message from being pulled off the queue if FTP is
unavailable? If not can I use a transaction tag?
3. Is upgrading to Camel 2.5 as easy as replacing the Camel jars in
ActiveMQ's lib? Any caveats with upgrading this way?

Thanks

--
View this message in context: http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4902912.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Search Discussions

  • Claus Ibsen at Oct 15, 2011 at 8:58 am

    On Fri, Oct 14, 2011 at 5:05 PM, pkleczka wrote:
    Hello

    I am using Camel 2.4.0 with Spring DSL and ActiveMQ 5.4.2. I have a route
    that takes a message off a queue, grabs the correlation ID in order to
    create a file name, and then FTPs the message. I expected that any exception
    during this process would "roll back" so that the message would not be
    pulled off the queue.  FTP was unavailable due to some firewall changes, so
    my messages got pulled off the queue but never FTPd.

    I understand that if I use Camel 2.5 I can use
    throwExceptionOnConnectionFailed. My questions are:
    1. Will that prevent the message from being pulled off the queue if FTP is
    unavailable? If not can I use a transaction tag?
    3. Is upgrading to Camel 2.5 as easy as replacing the Camel jars in
    ActiveMQ's lib? Any caveats with upgrading this way?
    Are you using transacted JMS ?

    If not then the message is pulled off the queue immediately when Camel
    receives the message.
    You can use transacted JMS to have the message support rollback / commit.

    Thanks

    --
    View this message in context: http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4902912.html
    Sent from the Camel - Users mailing list archive at Nabble.com.


    --
    Claus Ibsen
    -----------------
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
  • Pkleczka at Oct 17, 2011 at 7:17 pm
    Thanks Claus

    I have added JMS Transactions (still in Camel 2.4.0) with no effect. I
    assume I now need to upgrade to Camel 2.5 and add
    'throwExceptionOnConnectionFailed' to the route I want to roll back. Can I
    upgrade to Camel 2.5 while keeping ActiveMQ 5.4.2?
    If so, how do I do the upgrade?

    On Sat, Oct 15, 2011 at 2:58 AM, Claus Ibsen-2 [via Camel] wrote:

    On Fri, Oct 14, 2011 at 5:05 PM, pkleczka <[hidden email]<http://user/SendEmail.jtp?type=node&node=4904861&i=0>>
    wrote:
    Hello

    I am using Camel 2.4.0 with Spring DSL and ActiveMQ 5.4.2. I have a route
    that takes a message off a queue, grabs the correlation ID in order to
    create a file name, and then FTPs the message. I expected that any exception
    during this process would "roll back" so that the message would not be
    pulled off the queue. FTP was unavailable due to some firewall changes, so
    my messages got pulled off the queue but never FTPd.

    I understand that if I use Camel 2.5 I can use
    throwExceptionOnConnectionFailed. My questions are:
    1. Will that prevent the message from being pulled off the queue if FTP is
    unavailable? If not can I use a transaction tag?
    3. Is upgrading to Camel 2.5 as easy as replacing the Camel jars in
    ActiveMQ's lib? Any caveats with upgrading this way?
    Are you using transacted JMS ?

    If not then the message is pulled off the queue immediately when Camel
    receives the message.
    You can use transacted JMS to have the message support rollback / commit.

    Thanks

    --
    View this message in context:
    http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4902912.html
    Sent from the Camel - Users mailing list archive at Nabble.com.


    --
    Claus Ibsen
    -----------------
    FuseSource
    Email: [hidden email]<http://user/SendEmail.jtp?type=node&node=4904861&i=1>
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/


    ------------------------------
    If you reply to this email, your message will be added to the discussion
    below:

    http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4904861.html
    To unsubscribe from FTP producer and exception or transaction, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4902912&code=cGtsZWN6a2FAZ21haWwuY29tfDQ5MDI5MTJ8OTY3NjE0OTg2>.

    --
    View this message in context: http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4911178.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Claus Ibsen at Oct 19, 2011 at 2:31 pm

    On Mon, Oct 17, 2011 at 9:17 PM, pkleczka wrote:
    Thanks Claus

    I have added JMS Transactions (still in Camel 2.4.0) with no effect. I
    assume I now need to upgrade to Camel 2.5 and add
    'throwExceptionOnConnectionFailed' to the route I want to roll back. Can I
    upgrade to Camel 2.5 while keeping ActiveMQ 5.4.2?
    If so, how do I do the upgrade?
    The option throwExceptionOnConnectionFailed is AFAIR only for the Ftp
    Consumer (eg to download from FTP server).
    When you upload to a FTP server from Camel you use the FtpProducer.
    And it ought to thrown an exception if this fails.
    Which then should cause the TX to rollback.

    You may try with the FTP and have some java bean where you throw an
    exception. And then check if the TX works, by rolling
    back the transaction.

    Eg to test without the FTP part, to get it working. And then add the
    FTP back, and that can narrow down the problem.

    If there is still an issue, then of course write here again, and we
    can try to reproduce the issue and see what's the problem is.

    On Sat, Oct 15, 2011 at 2:58 AM, Claus Ibsen-2 [via Camel] <
    ml-node+s465427n4904861h97@n5.nabble.com> wrote:
    On Fri, Oct 14, 2011 at 5:05 PM, pkleczka <[hidden email]<http://user/SendEmail.jtp?type=node&node=4904861&i=0>>
    wrote:
    Hello

    I am using Camel 2.4.0 with Spring DSL and ActiveMQ 5.4.2. I have a route
    that takes a message off a queue, grabs the correlation ID in order to
    create a file name, and then FTPs the message. I expected that any exception
    during this process would "roll back" so that the message would not be
    pulled off the queue.  FTP was unavailable due to some firewall changes, so
    my messages got pulled off the queue but never FTPd.

    I understand that if I use Camel 2.5 I can use
    throwExceptionOnConnectionFailed. My questions are:
    1. Will that prevent the message from being pulled off the queue if FTP is
    unavailable? If not can I use a transaction tag?
    3. Is upgrading to Camel 2.5 as easy as replacing the Camel jars in
    ActiveMQ's lib? Any caveats with upgrading this way?
    Are you using transacted JMS ?

    If not then the message is pulled off the queue immediately when Camel
    receives the message.
    You can use transacted JMS to have the message support rollback / commit.

    Thanks

    --
    View this message in context:
    http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4902912.html
    Sent from the Camel - Users mailing list archive at Nabble.com.


    --
    Claus Ibsen
    -----------------
    FuseSource
    Email: [hidden email]<http://user/SendEmail.jtp?type=node&node=4904861&i=1>
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/


    ------------------------------
    If you reply to this email, your message will be added to the discussion
    below:

    http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4904861.html
    To unsubscribe from FTP producer and exception or transaction, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4902912&code=cGtsZWN6a2FAZ21haWwuY29tfDQ5MDI5MTJ8OTY3NjE0OTg2>.

    --
    View this message in context: http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4911178.html
    Sent from the Camel - Users mailing list archive at Nabble.com.


    --
    Claus Ibsen
    -----------------
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
  • Pkleczka at Oct 22, 2011 at 12:48 am
    Thanks Claus, I got it working. But have one more question. Page 304 of the
    Camel in Action book has a note about using the Direct component for
    multiple routes because it says the messages must "be processed in the same
    thread context". I am not sure I understand this or how I would alter the
    two routes below so that a direct component would tie them together.


    &lt;!-- Validate that we pass Odyssey XSD or send to "rejected" queue
    --&gt;
    <route id="EFileBatchRequestSubmit">
    <from
    uri="properties:{{queue.efilebatch.request.validatedxsdbusrules}}" />
    &lt;!-- ... some operations here ... --&gt;
    <to uri="properties:{{queue.efilebatch.request.submitted}}" />
    </route>

    &lt;!-- Send to Odyssey ftp --&gt;
    <route id="EFileBatchRequestFTP">
    <from uri="properties:{{queue.efilebatch.request.submitted}}" />
    <transacted ref="PROPAGATION_REQUIRED" />
    <bean ref="formatFTPFileName" method="formatName" />
    <to
    uri="properties:{{ftp.efilebatch.request.submitted}}?fileName=${header.JMSCorrelationID}.xml"
    />
    <to uri="properties:{{log.efilebatch.request.submitted}}" />
    <wireTap
    uri="properties:{{queue.efilebatch.request.submitted.tap}}" />
    </route>

    *Would I do something like the following:*

    &lt;!-- Validate that we pass Odyssey XSD or send to "rejected" queue
    --&gt;
    <route id="EFileBatchRequestSubmit">
    <from
    uri="properties:{{queue.efilebatch.request.validatedxsdbusrules}}" />
    &lt;!-- ... some operations here ... --&gt;
    <to uri="properties:{{queue.efilebatch.request.submitted}}" />
    *<to uri="direct:tie" />*
    </route>

    &lt;!-- Send to Odyssey ftp --&gt;
    <route id="EFileBatchRequestFTP">
    *<to uri="direct:tie" /> &lt;!-- This replaces the: from
    uri="properties:{{queue.efilebatch.request.submitted}}" --&gt;*
    <transacted ref="PROPAGATION_REQUIRED" />
    <bean ref="formatFTPFileName" method="formatName" />
    <to
    uri="properties:{{ftp.efilebatch.request.submitted}}?fileName=${header.JMSCorrelationID}.xml"
    />
    <to uri="properties:{{log.efilebatch.request.submitted}}" />
    <wireTap
    uri="properties:{{queue.efilebatch.request.submitted.tap}}" />
    </route>


    --
    View this message in context: http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4926428.html
    Sent from the Camel - Users mailing list archive at Nabble.com.
  • Claus Ibsen at Oct 22, 2011 at 8:23 am

    On Sat, Oct 22, 2011 at 2:47 AM, pkleczka wrote:
    Thanks Claus, I got it working. But have one more question. Page 304 of the
    Camel in Action book has a note about using the Direct component for
    multiple routes because it says the messages must "be processed in the same
    thread context". I am not sure I understand this or how I would alter the
    two routes below so that a direct component would tie them together.
    Yeah using direct can tie routes together like

    from X
    to direct:foo

    from direct:foo
    to Y


    About p304. Yeah its how the transaction manager requires this currently.
    So for example if the 2nd route does some transactional work, like
    writing a record in a database using JDBC.
    And the 1st route pickup messages from a JMS broker. And you want
    these two routes tied together, and
    work in the same atomic transaction, then the JMS consumer and the
    JDBC producer must run in the same thread.
    And hence you should use the direct component to tie the routes together.


    We are looking into support asynchronous transaction in the future (eg
    in Camel 3.x).
    So a TX manager can suspend an ongoing transaction, and handover this
    to another thread, which can resume the transaction, and so forth.


    &lt;!-- Validate that we pass Odyssey XSD or send to "rejected" queue
    --&gt;
    <route id="EFileBatchRequestSubmit">
    <from
    uri="properties:{{queue.efilebatch.request.validatedxsdbusrules}}" />
    &lt;!-- ... some operations here ... --&gt;
    <to uri="properties:{{queue.efilebatch.request.submitted}}" />
    </route>

    &lt;!-- Send to Odyssey ftp --&gt;
    <route id="EFileBatchRequestFTP">
    <from uri="properties:{{queue.efilebatch.request.submitted}}" />
    <transacted ref="PROPAGATION_REQUIRED" />
    <bean ref="formatFTPFileName" method="formatName" />
    <to
    uri="properties:{{ftp.efilebatch.request.submitted}}?fileName=${header.JMSCorrelationID}.xml"
    />
    <to uri="properties:{{log.efilebatch.request.submitted}}" />
    <wireTap
    uri="properties:{{queue.efilebatch.request.submitted.tap}}" />
    </route>

    *Would I do something like the following:*

    &lt;!-- Validate that we pass Odyssey XSD or send to "rejected" queue
    --&gt;
    <route id="EFileBatchRequestSubmit">
    <from
    uri="properties:{{queue.efilebatch.request.validatedxsdbusrules}}" />
    &lt;!-- ... some operations here ... --&gt;
    <to uri="properties:{{queue.efilebatch.request.submitted}}" />
    *<to uri="direct:tie" />*
    </route>

    &lt;!-- Send to Odyssey ftp --&gt;
    <route id="EFileBatchRequestFTP">
    *<to uri="direct:tie" /> &lt;!-- This replaces the: from
    uri="properties:{{queue.efilebatch.request.submitted}}" --&gt;*
    <transacted ref="PROPAGATION_REQUIRED" />
    <bean ref="formatFTPFileName" method="formatName" />
    <to
    uri="properties:{{ftp.efilebatch.request.submitted}}?fileName=${header.JMSCorrelationID}.xml"
    />
    <to uri="properties:{{log.efilebatch.request.submitted}}" />
    <wireTap
    uri="properties:{{queue.efilebatch.request.submitted.tap}}" />
    </route>


    --
    View this message in context: http://camel.465427.n5.nabble.com/FTP-producer-and-exception-or-transaction-tp4902912p4926428.html
    Sent from the Camel - Users mailing list archive at Nabble.com.


    --
    Claus Ibsen
    -----------------
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedOct 14, '11 at 3:06p
activeOct 22, '11 at 8:23a
posts6
users2
websitecamel.apache.org

2 users in discussion

Claus Ibsen: 3 posts Pkleczka: 3 posts

People

Translate

site design / logo © 2022 Grokbase