I am using camel SFTP. It looks like the connections are getting created on each poll but never closed. Camel v2.19.
Same setting work's fine with SMB.
sftp://user#server.com:22/Cdm_extract?delay=90000&include=.*.*&localWorkDirectory=%2Ftmp&password=xxxxxx&readLock=changed&readLockCheckInterval=20000&readLockLoggingLevel=OFF&readLockTimeout=60000"
You can use disconnect=true to close the connection after the poll.
Related
I have a reliable acquisition flow where an inbound SFTP connector is polling and reading the file and publishing to JMS ActiveMq. I have an issue when ActiveMQ is down. JMS connector get in to reconnection mode lets say every minute but SFTP is actively reading the files and try to publish the file in ActiveMq. which causes the loss of message and the concept of deadletter queue also does not work as JMS is down.
Is there a way we can stop reading the file until the JMS successfully reconnect? also what if the message was in flight and JMS get down before message end up in the queue? will the message rollback?
I am using Mule 3.9
If you set the flow processing strategy to synchronous and use only 1 receiver thread in the connector configuration. Then it should not try to read a new file if the previous one wasn't processed. Without those changes it is not a correct implementation of the reliable pattern.
More information:
Documentation of reliable patterns: https://docs.mulesoft.com/mule-runtime/3.9/reliability-patterns.
KB Article: https://help.mulesoft.com/s/article/How-to-fetch-files-in-order-using-the-FTP-connector
Example:
<sftp:connector name="sftpConn">
<receiver-threading-profile maxThreadsActive="1" />
</sftp:connector>
<flow name="mainFlow" processingStrategy="synchronous">
...
I have an application that uses Camel Netty4 component as a consumer endpoint which is configured as a TCP client (clientMode set to true) with the reconnect option enabled. The reconnect feature works well, the TCP client automatically reconnects to the remote server after a connection outage. Unfortunately it seems that this reconnect behavior runs indefinitely until the connection is established. Is there some way to set a limit to this reconnect feature, i.e. put a limit on how many reconnect attempts can be made before throwing a connection error?
Another question but this one is for the Netty4 component implemented as a producer that sends a payload to a remote server. Is there a way to configure the endpoint to enable the reconnect feature which would allow the TCP client to try establish a connection for a number of attempts before throwing a connection error?
In Camel 2.17-SNAPSHOT, there is no way to limit the amount of reconnection attempts. The reconnection is handled by ClientModeTCPNettyServerBootstrapFactory#scheduleReconnect. See here.
Currently it doesn't track the number of attempts, but it would be pretty simple to implement this functionality by adding a counter inside the anonymous Runnable.
Could you please open a ticket in the Camel JIRA?
Thanks!
I dont think limit for retry feature is avaialble at present for consumer, but you can specify the interval in which these retries can happen , the timeunit is in milliseconds.
I am trying to pull files from a remote server and if not able to connect to remote server want to implement below scenarios:
Would like to retry 'N' times,
If the connection is not successful after retrying want to stop polling and throw an exception to consumer saying "Server is not responding"
In your route you need a bean that connects to the remote server. If it can't connect, it should through an exception.
Then add an onException handler in your route
onException(CannotConnectException.class)
.maximumRedeliveries(3)
.processRef("doSomething")
The "doSomething" process has to take care of stop polling and inform consumer part of the route. For example, to stop polling you could call a method of the connection bean to stop it polling. The best solution is really going to depend on how you rest of your system fits together.
I would use a polling strategy for this. So the commit and rollback methods will decide on what to do if there is an issue with the route of some sort
Trying to set up a route with transaction handling on a camel, this leads to connection to the activeMQ drop and reconnect every few milliseconds is this expected, is there a work around?
Logs showing repeatedly reconnecting to ActiveMQ server:
ActiveMQ FailoverTransport Successfully connected to ssl://serveraddress:61617
ActiveMQ FailoverTransport Successfully connected to ssl://serveraddress:61617
ActiveMQ FailoverTransport Successfully connected to ssl://serveraddress:61617
Changed connection factory to use CachingConnectionFactory, also tweaked configurations to incorporate caching connection.
Some AMQP enabled brokers like Microsoft Service Bus or ActiveMQ allow only one active producer or consumer per session. The Apache JMS Camel component seems not be able to handle this correctly, which result that JMS throws exceptions when processing InOut messages sent from e.g. Service Bus.
A small JMS test application with separate sessions for producer and consumer works nice. With using the same session, it run into the same problem.
Issue is rooted in the Spring JMS template, which is used as base for the Camel JMS implementation.
Does anybody know how to overcome that behavior?
You can define a 2nd JMS component and use that for the "other".
Or you can turn off any kind of connection pooling maybe.
If you use XML then you can define a 2nd jms component
<bean id="jms2" class="org.apache.camel.component.jms.JmsComponent"/>