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.
Related
I am using a openssl library to implement tls server.
How to configure the Heartbeat request timeout and retry count using openssl API to control the keepalive message flow?
I'm assuming you really do mean TLS as you said and not DTLS. Using heartbeats in TLS is quite unusual, although OpenSSL does support it in version 1.0.2. That support is removed from OpenSSL 1.1.0 so, for that reason, I would advise against using it in a new application. Use TCP keep alives instead.
The Heartbeat API is really quite simple. You can do three things:
1) Send a heartbeat using SSL_heartbeat()
2) Find out if a previously sent heartbeat is still pending a response using SSL_get_tlsext_heartbeat_pending()
and
3) Set the Heartbeat mode to disallow the peer from sending heartbeat requests using SSL_set_tlsext_heartbeat_no_requests()
Anything else is up to the application. Retries should not be necessary in TLS because it is designed to run over a reliable transport layer. If the connection is alive, it will get there. If it isn't, it won't. The TCP layer will handle retransmission of lost packets. Timeouts should also really be done at the TCP layer. If the TCP connection times out the SSL connection will fail.
Today I had a problem searching songs on Deezer API. The server was blocking my requests.
A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection
failed because connected host has failed to respond 195.244.30.137:80
What do I need to do so that it wouldn't happen again?
I solved my problem.
There was a internet problem in my side.
Sorry
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.
we wrote in C++ a screen sharing application based on sending screenshots.
It works by establishing a TCP connection btw the server and client, where the server forwards every new screenshot received for a user through the connection, and this is popped-up by the client.
Now, we are trying to host this on google app engine, and therefore need 'servlet'-ize and 'sandbox' the server code, so to implement this forwarding through HTTP requests.
I immagine the following:
1. Post request with the screenshot as multiple-data form (apache uploads ..).
But now the server needs to contact the specified client (who is logged in) to send it/forward the screenshot.
I'm not sure how to 'initiate' such connection from the servlet to the client. The client doesn't run any servlet environment (of course).
I know HTTP 1.1 mantains a TCP connection, but it seems gapps won't let me use it.
1 approaches that comes to mind is to send a CONTINUE 100 to every logged in user at login, and respond with the screenshot once it arrives. Upon receival the client makes another request, and so on.
an alternative (insipired from setting the refresh header for a browser) would be to have the app pool on a regular basis (every 5 secs).
You're not going to be able to do this effectively on GAE.
Problem 1: All output is buffered until your handler returns.
Problem 2: Quotas & Limits:
Some features impose limits unrelated
to quotas to protect the stability of
the system. For example, when an
application is called to serve a web
request, it must issue a response
within 30 seconds. If the application
takes too long, the process is
terminated and the server returns an
error code to the user. The request
timeout is dynamic, and may be
shortened if a request handler reaches
its timeout frequently to conserve
resources.
Comet support is on the product roadmap, but to me your app still seems like a poor fit for a GAE application.
Long Polling is the concept used for such asynchronous communications between server and client.
In Long Polling, servlet keeps a map of client and associated messages. Key of Map being client id and value being list of messages to be sent to the client. When a client opens a connection with server (sends request to a servlet), the servlet checks the Map if there are any messages to be sent to it. If found, it sends the messages to the client exits from the method. On receiving messages, the client opens a new connection to the server. If the servlet does not find any messages for given client, it waits till the Map gets updated with messages for given client.
This is a late reply, I'm aware, but I believe that Google have an answer for this requirement: the Channel API.