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.
Related
Bit of a Camel newbie but here goes.
I have the following route:
from("activemq:queue:outputQueue").inputType(HelloWorld.class)
.to("log:stream")
.marshal().json(JsonLibrary.Jackson, HelloWorld.class)
.to("http:localhost:5000/messageForYouSir?bridgeEndpoint=true");
This retrieves messages from the queue and sends them to the HTTP endpoint as JSON. Fine.
But what if there is an error? Say a HTTP error code of 400? Then I want the message to stay on the queue. I have tried looking into not acknowledging the message, but have not been able to make it work.
Also I have made an Exception handler
onException(HttpOperationFailedException.class)
.handled(false)
.setBody().constant("Vi fekk ein feil");
But still the messages are gone from the queue. Is there some magic spell that can make Camel not acknowledge the messages when there is some error?
You have to consume transacted from the queue to be able to do a rollback. This is configured on the connection configuration to the broker.
Take a look at the Camel JMS docs (the ActiveMQ component extends the JMS component), especially the sections about cache levels and transacted consumption.
The most simple setup is using broker transactions by simply set transacted = true and lazyCreateTransactionManager = false on the JmsConfiguration. This way no Spring TX manager is required.
If transacted consumption is in place and the HTTP server returns an error (basically if an Exception occurs in the Camel Route), Camel does automatically a rollback (if you don't catch the error).
I am trying to setup a camel context that polls a weblogic jms queue, consumes the message and sends it to a webservice endpoint. Incase any error occurs in the transaction or the target system is unavailable, I need to redeliver the same message without losing sequence/ordering.
I have set up a camel jms route with single consumer and enabled transacted attribute as per https://camel.apache.org/transactional-client.html and set the redelivery as unlimited.
When the transaction fails with messageA, the jms message consumption from weblogic queue is rollbacked and the messageA is marked for redelivery (state string is marked delayed) in weblogic. But during this time if another message reaches the weblogic queue, the camel route picks the messageB and forwards it to the target endpoint although the messageA is still in retrying mode. This distorts the whole ordering of the messages.
The transaction client is used to ensure that messages are not lost while the application is shutdown during redelivery.
I expect that there are no message loss and the messages are always sent in the correct order as per generated into the weblogic queue to the target endpoint.
That a newly arrived message outpaces an existing message that has to be redelivered, sounds like a broker (Weblogic) issue or feature.
I never saw this behavior with ActiveMQ. A failed message that is redelivered, is redelivered immediately by the Apache broker.
It sounds like the message is "put aside" internally to redeliver it later. This can absolutely make sense to avoid blocking message processing.
Is there something like a "redelivery delay" set on Weblogic you can configure? I could imagine that a delayed redelivery is like an internal error queue with a scheduled consumer.
I have:
Camel route (transacted=true), consuming from an MQ Queue
Using Spring's WebSphereUowTransactionManager
Transactionality works
Running on IBM Liberty
But, I get this message:
Setup of JMS message listener invoker failed for destination 'MY.QUEUE' - trying to recover.
Cause: Local JMS transaction failed to commit; nested exception is com.ibm.msg.client.jms.DetailedIllegalStateException:
MQJCA1020: The session is closed.
The application attempted to use a JMS session after it had closed the session.
Modify the application so that it closes the JMS session only after it has finished using the session.
This appears to be related to this other Stack Overflow question, but I've tried changing the configuration in server.xml, with no success.
You can try setting cacheLevelName=CACHE_CONSUMER which allows to re-use the JMS consumer and avoids endless of creation/destruction of JMS resources, as indicated by the error message may be the cause.
You can see more about the importanse of cache levels on the Camel JMS documentation: http://camel.apache.org/jms
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